...but it's the only use of that tool apparently (hoping that libtool
merely checks for it for decorative purposes) so perhaps we can do
without another config_host.mk variable...

Change-Id: I2a0dec4c01dc8ad3327b34a99c807705fedcdd00

Change-Id: I000824e86f40ce20af2d254dc848b51321602760

Change-Id: I124e913160e2841bfaab5112395d4a76d761a0d4

Change-Id: I745d51c5b8f4296c00ae1b652b42a311d89a0ed9

The system strlcat() might be some clever built-in or macro thing
anyway, and having a bogus duplicate declaration can cause
problems. And does, in the iOS 7 SDK.

Change-Id: I0aed0ad0f7b96c1c887ed928a2c07fc99bd703f7

Change-Id: I2989e2aea344a7079a6da158ca318c3496c813ff

Project: help  c072ef65d773a788a30efd0453a92ed3f558a30c

Change-Id: I00e04ba603da8b07d53a9e23134fa01ea1ab3f0b

Project: help  f0beeb7af869bbc527613d0c300e80549f7723ec

Change-Id: Idedefb7bdd37ba2039112707510afc030718e281

... used to build, since otherwise it'll break with "malformed object"
errors.  Alo replace now unused XCRUN variable.

Change-Id: I58a20c34f903b7a7acb46597d94243389e6b3842

calling back() on empty vector results in undef behaviour

Crash originally reported here:
http://lists.freedesktop.org/archives/libreoffice/2013-September/055827.html

Change-Id: Ibefdc7e2495fc31d748c16fedd3cee5eb957bfa2

Change-Id: If77e1165efec7e8ef008beaeb4e6d17997ee416c

... and also export DEVELOPER_DIR so that xcrun returns CC and CXX
values that match each other and the found SDK too, which was not
previously the case on oddly set up machines with multiple SDKs.

Change-Id: Iaed362b369b558b706926f1d15d170db580a4724

Macro Expansion function is used in 'CustomAnimationPreset.cxx'
& 'TransitionPreset.cxx' to avoid code redundancy.Also appropriate
changes are to made to 'getExpandedFilePath' function.

Change-Id: I6b6ae068db3499fe2de2e78a884f9e0737577651
Reviewed-on: https://gerrit.libreoffice.org/5910Reviewed-by: Thorsten Behrens <thb@documentfoundation.org>
Tested-by: Thorsten Behrens <thb@documentfoundation.org>

Change-Id: Iecb8104ea2891d5229e3ecace54e12287d9b0ac6

Change-Id: If2a5ce7d9163c9ef1862850ec3b89a5e600e9636

Change-Id: Ic573e5ae63fdfb3d4ff79eb6d81fe0f4b058d582

Change-Id: Icc55a6b485341e3be0d3e96f51f41a2bba1629c1

Change-Id: I467494c1731999c50883f96301b00a3dc1282c73

Change-Id: Ifafcbe6ed88a2cc18ecb1ff123adf974e10e5187

The typo causes spurious re-builds and error messages about the
dep-target.

Change-Id: Ia8bc236759c7ef13f81fe91c88f467d6e507bf29

Change-Id: I14d6a7e4a53e65070357a2a5ceab3b25498a9fd4
Reviewed-on: https://gerrit.libreoffice.org/5933Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>

This removes nearly all ToLowerAscii() calls.

Conflicts:
	linguistic/source/convdic.cxx
	linguistic/source/convdiclist.cxx
	linguistic/source/dlistimp.cxx
	sc/source/filter/html/htmlexp.cxx

Change-Id: Iddcaacfb7383e1df3d2f13751a3c788eba953fdd
Reviewed-on: https://gerrit.libreoffice.org/5895Tested-by: Caolán McNamara <caolanm@redhat.com>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>

Change-Id: I3a2f1ff990495c818a07e7c5b1d1ed509273f286

Change-Id: If1b4125fa0757fdcdff5466bf9b99791c930ffa6

Project: help  cff95cb4ac050718c0ac7c9e37c5946ce4467c95

this one nearly killed me

Change-Id: I51f14017940a275cca33dacf6f42438da43f46bc

Change-Id: I8c071dd76e9ea84ee9aaf9cdd06b2103df4fd789

Change-Id: Id30805f09bc359c6f66d87f050427c0e586ec93d

not only one.

Change-Id: I1f611dda6a98fb6244409c0cd1fc87fc9dfaa8c3

Change-Id: I709305d4ec3c37d3fc1c2c911551174f8cfbb883

as opposed to table columns or other expressions.
So it makes no sense to slap a table name on them.
Notwithstanding HSQLDB 1.8 (our embedded database) bugs.

Change-Id: Ib5d0b1479e29b9efeafca9ebc2eb7ed8e0f42b79

Change-Id: I8660ae764c7dd51b8d780929effe895243e4fc4c

the layout changes for the basic IDE ( for the object browser and object
catalog ) seem flacky, I have seen since those changes have been introduced
some strange ( but random ) behaviour ( like the odd unrepeatable core ( maybe
related to this ) and also sometimes Modules appearing in the tree under the
wrong nodes etc. I'm no expert in the basic IDE code but this patch seems to
fix the problem.
However there is one drawback, in the core inducing scenario the tree view
( object catalog ) dissappears, this is because the patch suppresses the
problematic layout in this case ( as the layout seem not to be currently able
to deal with 'no-existent' (recently) deleted current window )
Probably in this scenario a fallback currentwin (instead of nil) could be set
this would behave better but ideally. Ultimately the layout class should
probably be modified ( possibly redesigned )

Change-Id: I9d1e23bd6fc4aae32aa78da8278c318f7051136a

...post 68e2a4e4 "Revert 'Visibility doesn't
seem to work as we want in Apple's Clang.'"

Quoting <https://developer.apple.com/library/mac/documentation/developertools/
Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html> section "Symbol
Visibility and Objective-C:"  "When building for x86_64 OS X or for iOS, symbol
visibility /does/ affect objective-C classes.  [...]  This means that if a given
class is intended to be usable outside the library or executable it's defined
in, you need to ensure proper symbol visibility."

The chosen syntax works at least with both --en/disable-64-bit "experimental"
(Clang-based) builds on OS X 10.8.  Hopefully, it also works for baseline
builds.  (Also, it could be that a more fine grained use of
SAL_DLLPUBLIC_EXPORT/SAL_DLLPRIVATE would be useful, but with the current setup
at least linking of Library_vcl against Library_AppleRemote works.)

Change-Id: Iff4fe9e50d1400c83879f62fe29b35bd19d58eb8

Change-Id: Icd832483228812cf3c8ddff3c0d56090f3b17856

When exporting a Frame that contains an eDrawing, check whether it's
a diagram and export it properly if so.

Exporting the diagram means adding the relations for the four
mandatory files (data, layout, quickStyle and colors), and the
optional one (drawing), and also writing those from the imported
XDocuments to the respective files.

If the drawing file exists, the data XDocument must be updated before
writing it to disk, as it contains a reference to the drawing file
that must be updated with the new relation id.

With this change, the files saved to docx that contain SmartArt will
be properly opened by MS Word without data loss.
LibreOffice won't be able to properly open saved files though, as
it requires the theme file to be present, and it's not being
exported yet. This is planned to be fixed in an upcoming patch.

Change-Id: If69ca9815dd076597a37937fe2af8ed4d1c7acc5
Reviewed-on: https://gerrit.libreoffice.org/5896Reviewed-by: Thorsten Behrens <thb@documentfoundation.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
Tested-by: Miklos Vajna <vmiklos@collabora.co.uk>

Change-Id: I8484be77353b288b6dfaa0d86fa4b325fd1187a5

Change-Id: Ie3e2f6c9d1b8ff75b8450e8c377073821d0f1b37