Change-Id: I7db1f2ab6fa842ed9750e8240fa813ba1bbc59b2

Change-Id: Iedb82a17fb7f7e3d16e86dc2a451c8aac4be9149

Change-Id: I1cbb247cb95e412c9e62b36510ad5e58a60ebfdc

Change-Id: I I7de285ae784ae144a7d3190d4f99c1b38694da28

Change-Id: Ie5bc60875fef3e9b6f6f46942b2124bc42978290

Change-Id: I3b41aca08f23b65277947b94423a0e2a2e91b023

Change-Id: Ie874ba4c5bffbd36d38868b0602687c64649c3f0

Change-Id: I85364368d2ffca717b38d17c3396f53699001a3f

Change-Id: I4b560e276bd0026e90e8a27238fe3f588cf91e55

Change-Id: I56801d8ce1a9bb6f8f9faebdf15ce831b7e9ea3d

Change-Id: I7e5d0abbf209fd975a1f886b2588b51e05cf35e7

Change-Id: I43aba3046fb0c7adcf5362ea26273189addc12fe

Treat date and time field types together, and handle appropriate
properties to have it not throw UnknownPropertyValue exception.

Change-Id: I6a4c512fb3030bfc48ab7372cb1a217069dedfc4

Change-Id: Ifa8210ffdf29624689f547b436fd687a2de82eb1

Change-Id: Id1ccae62037369917a46d620c0c46ac2447a0910

Change-Id: I3d1d4c1e9adebda16c62f4e14bd5aca14e058605

Change-Id: I Ie868d9d2d8d56459f2013d91f836736cd3fd4d72

Change-Id: I4ac3e017f1450a14d2bb389b72ffd2e69cc5767a

These are all derived from the SalLayout interface, with a similar
GetTextBreak() implementation. MultiSalLayout didn't break text that had
exactly the same length as the available space, the other two did. Fix
this inconsistency.

Change-Id: Icd9a81e039492bee82c28b8d8582e3a161dfd283

Change-Id: Iabfbe3f4df2c73ad9325bdc60e4ad71a5d1fda15

Just using the identifier ScriptIsComplex apparently results in the
address of its import stub, which has been linked into the calling DLL
(vcllo.dll). We need to look up that symbols from the handle of
usp10.dll to get the actual function's address, to be passed to
osl_getModuleURLFromAddress().

(Nothing magic with ScriptIsComplex here, it is just an arbitrary
function from usp10.dll.)

Change-Id: I If000d0c2eae3e3e32ce0ad1c26e545304d6f6d9e

We don't use the debugging runtime in LO's own code in dbgutil builds,
so we shouldn't use it in bundled libs either.

(At one point I did try to use the debugging runtime in a dbgutil
build, but had to give up eventually; too many compilation errors
thanks to using -D_DEBUG which brings in much more strict checks in
the C++ headers. I apparently forgot to fix these makefiles then when
I aborted the attempt.)

Change-Id: I I Iedf765b55ba71b811d7fe3074e4c3129783108fd

Change-Id: I706593f0017d440b486f698d1158f070df4e8b2e

Change-Id: I6bf22a22c41860a85af4e01ee23b146265863797

Change-Id: I9d7b80ebd6d251e2ac6d16899e23584582e8f461

which is no longer relevant since 6a64e5bb

This reverts commit 31182ed0.

Change-Id: Idbcd6b2e21b1e0e93b167c78ff361c81cf25c978

this follows b07d7d34

Change-Id: I41001cec7b8024c9c957481b31ab6bf3badf0abe

This reverts commit 16c9d63d.

Conflicts:

	svtools/source/contnr/svimpbox.cxx

Change-Id: I8e030e3b85fbf31d8369646e55048b830a83486e

/oox/source/dump/dumperbase.cxx:345:69: error: dereferencing type-punned
pointer will break strict-aliasing rules [-Werror=strict-aliasing]

gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC):
/rtl/string.hxx:1037:67: error: assuming signed overflow does not occur
when assuming that (X + c) < X is always false [-Werror=strict-overflow]

gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC):
/rtl/ustring.hxx:1293:233:
error: assuming signed overflow does not occur when assuming that (X -
c) > X is always false [-Werror=strict-overflow]

gcc version 4.6.3 20120306 (Red Hat 4.6.3-2) (GCC):
/com/sun/star/uno/Sequence.hxx:178:10: error: assuming signed overflow
does not occur when assuming that (X - c) > X is always false
[-Werror=strict-overflow]

Let --enable-debug determine whether optimization should be disabled,
which works also for debug=t due to the setup in gbuild.mk.

Also clean up uses of gb_COMPILEROPTFLAGS: this is now always set to
optimization settings, and gb_COMPILERNOOPTFLAGS used in debug case,
which should not make a difference because the only actual difference
was that on MSVC the debug OPTFLAGS were empty, but -Od is documented as
the default for this.

OOo used to use debug level this way:
0 is default for product build
1 for --enable-dbgutil
2 for environment variable debug=t, regardless of dbgutil setting
in LO these have now morphed into:
0 is default for product build
1 for environment variable debug=t
2 for --enable-dbgutil (at some intermediate stage in the past)
1 for --enable-dbgutil (today)

This has caused a lot of confusion and some things were not converted
properly, including a check in LinkTarget.mk.

Developers should use --enable-debug to get useful information,
including full debug info and assertions.

--enable-symbols is not intended for developers, but for people
who need their builds to be able to produce useful stack traces;
--enable-symbols is for example set unconditionally in the Fedora RPM
spec, and for this purpose disabling of inlining is not wanted.
It is unlikely that somebody wants symbols for only part of the build,
and consequently a different mechanism is used to set the corresponding
flags: they are set into global gb_LinkTarget_C{,XX}FLAGS.

So move the selective symbol feature back to --enable-debug.

(this substantially reverts db8df57a)

(was broken by ebed42c3)