In OOo times, there'd originally been efforts to allow building on Windows with
MinGW. Later, in LO times, this has been shifted to an attempt of cross-
compiling for Windows on Linux. That attempt can be considered abandoned, and
the relevant code rotting.
Due to this heritage, there are now three kinds of MinGW-specific code in LO:
* Code from the original OOo native Windows effort that is no longer relevant
for the LO cross-compilation effort, but has never been removed properly.
* Code from the original OOo native Windows effort that is re-purposed for the
LO cross-compilation effort.
* Code that has been added specifially for the LO cross-compilation effort.
All three kinds of code are removed.
(An unrelated, remaining use of MinGW is for --enable-build-unowinreg, utilizing
--with-mingw-cross-compiler, MINGWCXX, and MINGWSTRIP.)
Change-Id: I49daad8669b4cbe49fa923050c4a4a6ff7dda568
Reviewed-on: https://gerrit.libreoffice.org/34127
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...and remove some unncessary using directives/declarations, in preparation of
removing now-unnecessary #includes from cppumaker-generated files, post
e57ca02849c3d87142ff5ff9099a212e72b8139c "Remove dynamic exception
specifications".
Change-Id: Iaf1f268871e2ee1d1c76cf90f03557527ebc9067
I /think/ a set-but-null LD_LIBRARY_PATH (Linux), DYLD_LIBRARY_PATH (macOS) are
each treated like an unset one.
Change-Id: If60698d6f21a16456dac9c3d4f4e1aa3561e1a65
In a build with -fsanitize=address, this fails with:
Change-Id: If8581363a395af78bbbe00dd656290aea53af330
make: symbol lookup error: instdir/program/libfreebl3.so: undefined symbol: __asan_option_detect_stack_use_after_return
Only on macOS, the SDK used to expect javac etc. in a Commands sub-dir (which
Apple's JDK 1.6.0 has but Oracle's JDK 1.8.x don't). However, at least both
Apple's latest JDK 1.6.0 (as available via <https://support.apple.com/kb/DL1572>
"Download Java for OS X 2015-001") and any recent Oracle JDK 1.8.x (like
jdk1.8.0_121.jdk) have a Home sub-dir that contains a "standard" sub-tree with
bin sub-dir etc., like on other platforms. So consistently make the SDK use
that instead.
This removes the JAVABIN Make variable from settings.mk. It is assumed to not
be used by client code.
Change-Id: Ie0ad647f489528444dfd399c2f00500b772d3288
...changed with f88f6bcfce233c336c9025d466c5c2fb0b671de3 "Resolves: tdf#35247
introduce a locale independent numeric field filter".
Makes the example at least compile again. No idea whether any of the values
reported by getLocaleIndependentElementNames would actually need to be different
from those reported by getElementNames for this exampel.
Change-Id: I115096477b28a4ceea398cbbb473a707141d05aa
(sal/inc/rtllifecycle.h only hits on Windows as that is the only platform that happens to
actually include it in a C compilation unit, sal/osl/w32/dllentry.c)
Change-Id: I2878b52daf713ea45eaa2968cc5d2686b86abfe6
...containing replacements for global operator new/delete (that can be linked
into executables), but which is no longer used. The mail thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2012-March/028690.html>
"operator new no longer routes through rtl_AllocMemory in libsalcpprt under
gbuild link rules" has the details of how this was used on some platforms (but
not on others) before the switch to gbuild, and has been "lost" ever since---but
apparently a loss not mourned much over the years.
For the SDK, c5f974287fd04bb529de145113133b9e35687702 "INTEGRATION: CWS jsc3:
#i62434# copy libsalcpprt.a" added the library (under Linux) and
6db9c5af960f9787e33e4addc56bddbb1695a402 "INTEGRATION: CWS jsc3: #i62434# extend
link options for executbales to link libsalcpprt.a, LINUX only" added its use to
odk/settings/settings.mk, but fc0ca57f2cd649c6330171445a06b80e2143a0e9
"INTEGRATION: CWS jsc21" removed that use again (for no documented reason). So
this is an incompatible change, but unlikely to actually affect any users of the
SDK.
Change-Id: Ia38b4c439f21fca3f5d9af7d1a34054e992054e9
Reviewed-on: https://gerrit.libreoffice.org/31810
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
...which isn't true at least ever since b525a3115f54576017a576ff842dede5e2e3545d
"initial import", but got copy/pasted all over the place
Change-Id: I47d3d8a594aef3ac3736d7176ae964a118821014
makeAny and Any ctor return an Any
Change-Id: Iaa361bc315d785f80153acf1009bf47d109728ec
Reviewed-on: https://gerrit.libreoffice.org/29914
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Replace it with the Help on Help command
Change-Id: Ia454a2f6a123b4fb68fda1eae1e07e99ba81487f
Reviewed-on: https://gerrit.libreoffice.org/29381
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Miklos Vajna <vmiklos@collabora.co.uk>
* GCC documents -fvisibility at least as far back as the GCC 4.0 online
documentation at
<https://gcc.gnu.org/onlinedocs/gcc-4.0.4/gcc/Code-Gen-Options.html>.
* For external code, odk/settings/settings.mk unconditionally set
HAVE_GCC_VISIBILITY_FEATURE for all platforms other than Windows.
Make this a fatal configure error for now. The check should be removed
completely after LO 5.3 branch-off.
Change-Id: I1de415b6ed1591e0a7b6640ece861b6f0ef74112
Reviewed-on: https://gerrit.libreoffice.org/29073
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
See http://listarchives.libreoffice.org/global/users/msg49357.html
odk/settings/std.mk currently adds each .class file separately,
therefore having to be updated manually any time one class or
anonymous class is added, removed etc.; all the .class files in
com/sun/star/lib/loader/ are needed in the jar anyway, so use a
generic makefile rule.
Change-Id: I3819ab94e2c056220993971de44408e46a4559ed
Reviewed-on: https://gerrit.libreoffice.org/28317
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
Reviewed-by: jan iversen <jani@documentfoundation.org>
...that was added with both c4c10c17adfb139a208deeb1a47a9fcad924b9c3
"INTEGRATION: CWS sb87: #i88687# let Loader call new unoinfo instead of old
juh.jar UnoInfo.getJars" and 9d53b3321881bd54526f08a9219c539c1430f2b5
"INTEGRATION: CWS jsc21"
Change-Id: I355cbd933e3cff76416d02af8d6717326e0f3cb7
...that was introduced with abbf4777f29374025d576ef8daa3f6dcba02ddf5
"cid#1326844: DP: Use doPrivileged"
Change-Id: I8cd4d947b258313d4d171c5888490d1a860ebee7
...so that the JNI UNO bridge will not accidentally reinterpret a Short[] as a
short[]. <https://wiki.openoffice.org/wiki/Uno/Java/Specifications/Type_Mapping>
makes it clear that the former is not a valid Java representation for UNO type
"sequence of short".
Needed one fix in bogus test code. Also fixed the two bogus places in odk/examples
mentioned in f53e427291321eabe8d060a737e750a94739f911 "Resolves: tdf#99272 new
Short[] used instead of new short[]".
Change-Id: I8321eb1294ec77b3a9bf73cafb6e7fe337157bb7
Revert (parts of) various commits that tried to use LIBO_INTERNAL_ONLY features
in external odk/examples/ code.
Change-Id: I275c3e8979c995430329bca61e51b2841503234f
Searched source for using declarations.
Checked if those symbols reappear in the source file,
even in comments or dead code but not in #include statements.
If they don't reappear, remove the declaration.
Remove includes whose symbol got removed.
Change-Id: Ibb77163f63c1120070e9518e3dc0a78c6c59fab0
Reviewed-on: https://gerrit.libreoffice.org/24148
Reviewed-by: Jochen Nitschke <j.nitschke+logerrit@ok.de>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
Tested-by: Noel Grandin <noelgrandin@gmail.com>
Sequence.h(xx), Any.h(xx) and Type.h(xx)
and remove unused using-declarations from these files.
Add a few missing includes provided by them.
Change-Id: I6b91b6d1fdf9d0496dd546c0aab9bdcc6831a5d4
Reviewed-on: https://gerrit.libreoffice.org/23805
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Noel Grandin <noelgrandin@gmail.com>
