/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)

GNU coding standards say that user should be able to override the build
system's default flags with CFLAGS/CXXFLAGS environment vars;
also these ended up twice on the command line due to historic accident.

The previous commit works but results in a ~0.4 second slowdown on
tail_build, which is completely unacceptable; seems that at the cost of
another ugly global variable in Module.mk we can get the performance back
and then some, so refactor this again...

so it doesn't use wildcard but instead the actually registered
LinkTargets.

If in an imported Excel document with VBA a sheet to be copied does not have
a document object in the VBAProject container (whyever that may be the case)
the getByName() rightly throws a NoSuchElement exception. Catch that.

Change-Id: I I007724e0ea4cc54a72f9bd9de9d83f887615568e

Change-Id: I I I6df249fa1be37c7136baac03adcfb19fcf73e472

Change-Id: If00fb050a5634e76d3add87c1838fa99ff4715be

Change-Id: I52d2e0426d7f2822a05a74a82ca079fb80a87007

Default text may not make sense to be copied from the
master slide to the slides when there is an image.

Change-Id: I4a822a8f132f91c1b21ead4e1811b04323485356

When LibreOffice is compiled against the 10.6 SDK and run under gdb,
the apple_remote code caused "cannot init a class object" exception
messages to be printed.

Upon closer inspection this was caused by the call to [super init] in
the sendDistributedNotification class method of the RemoteControl
class.

As far as I understand, calling [super init] and assigning its return
value to self, even, is pointless and wrong in a class method.

This code apparently has not been causing any harm when built against
the 10.4 SDK. This is probably just accidental thanks to a more
lenient Objective-C runtime getting used?

When built against the 10.6 SDK, though, the resulting Objective-C
exception seemed to make input event handling non-functional. After
this fix LibreOffice built this way works better.

Change-Id: I I I383611753f3f83a9efa4694b1900c8b66ed1a8e3

Change-Id: I8ccb7be448faf42904eb6246a4f5a06ff8028ffc

Change-Id: I303a750058039a4df5a237c823178c8a065f04a4

Change-Id: I2ced06de50b145ab9a876679f1ec49dd8915fbf9

4478b739 "convert bean to gbuild and add to
tail_build" broke the following:
* The name of the officebean dynamic library must not be changed (by adding the
  "lo" extension), as code in officebean.jar uses it in NativeLibraryLoader.
* With gbuild's per-default hidden visibility, JNIEXPORT functions must instead
  use SAL_DLLPUBLIC_EXPORT.  (Windows-only code in bean/native/win32/ should be
  safe to continue using JNIEXPORT.)

Change-Id: I I3c312dd05c90421ba0c726496b7149a26d155604

...instead of NamingService.  Even though current
<http://wiki.services.openoffice.org/w/index.php?title=Documentation/DevGuide/JavaBean/Customized_Configuration&oldid=127145>
documents using the latter, it leads to NullPointerException, as connect()
expects aInitialObject to be an XPropertySet.

Change-Id: Ia8445bed5307bf440d078a8b96200e3b7fa38706

Change-Id: Ia134204af1747f570e3048b47c2e12415ceb56b3

Change-Id: I5f3b7f1bba1d751004399e4ea995acc813df3636

Change-Id: I63338f6c2cfa3d206260b536a44de3d51fcd5710

Change-Id: I13d969511dfb8cb87a88be47c72de4d882247f46

Change-Id: Ieaba4fe704cc588bd515b427a7f14008afea8c03

Change-Id: I61f54a76096f3d2390c16fb1715aa95761e761e5

Change-Id: Ifbb44b8d711b82f5d3ca0cd678579e9dcbb44bf2

Change-Id: I51eea9c45b893f56dece99e8d01e385c96051f8d

Change-Id: Id9fc99aab1515a710374b3364f6136587f95f582

Change-Id: I968fb58b6ceb406a62a2b403c270aef2281945c3

Change-Id: Ia559990745d10c2f128624b6ffe76ece8a9151b9

Change-Id: I6fcbe4db269472543e8b3310c966a68f5846a510

Change-Id: I0ae693193b4fc8ed155e2d71b06daa80d46da47c