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>
...as stoc/Library_javavm.mk depends on it since
9b09a217c7 "Resolves: #i86470# Wrong Java locale
when using 'nl' and 'fr'". The i18nlangtag lib in turn depends on libs from
external/liblangtag and external/icu, so those needed to be moved to URELIB,
too.
On Windows, the external icu package was already split into icu and icu_ure
(because "libxml2 is in URE and depends on icuuc*.dll on Windows"), so use that
splitting on all platforms. (However, the corresponding changes that were
necessary in RepositoryExternal.mk suggest that they had been missing for the
split Windows case until now, and things had happened to work by accident?)
On macOS, a library's install name reflects its (URELIB, OOO, ...) layer, and in
external/icu/icu4c-build.patch there is only a single place to set that for all
libs from external/icu. This patch changes that from OOO to URELIB, but for the
icui18n lib that should stay at OOO. The hack to make it URELIB nonetheless
works for now. To clean this up again, either the whole of icu could go into
URE (dropping the icu vs. icu_ure package split completely), or the macOS layers
URELIB and OOO could be combined into one (as the libs end up in the same
directory anyway).
Change-Id: Idc262fa41481d06ba2cae86ad7629cdccb392c07
Reviewed-on: https://gerrit.libreoffice.org/30272
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
A good way to get developers to add files is to print 80 lines of
stack trace multiple times on startup.
Change-Id: Id563ab1d26d32e6fe3f14b2afb59949ea04f0d6a
At least make-4.1-5.fc24.x86_64's /usr/bin/make (indirectly) links against
libfreebl3.so, so it could erroneously pick up our instdir/program/libfreebl3.so
delivered there from external/nss. But that's a problem for ASan/UBSan builds,
where that libfreebl3.so is instrumented and expects to find certain symbols
exported from the executable (and which /usr/bin/make of course doesn't have),
so running make from within external/liblangtag/ExternalProject_langtag.mk
fails.
Turns out that the only place where LD_LIBRARY_PATH is needed during the build
of external/liblangtag is when running
workdir/UnpackedTarget/langtag/data/reg2xml.
(This is unrelated to the recent changes to external/liblangtag by the way; just
happend to show up now by accident, when doing an incremental build where
external/nss had already been built when external/liblangtag got rebuilt.
external/firebird has a similar problem, but everybody seems to run ASan/UBSan
builds with --disable-firebird-sdbc anyway for now.)
Change-Id: I6e045b6d33a154e350f4640265e6568f96634187
Reviewed-on: https://gerrit.libreoffice.org/29211
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...after ecd5d49dc3 "liblangtag: prevent libtool
from adding annoying stuff to RPATH". "Outsmarting" libtool in the way
described in 1d028d4783 "Fix Linux RPATH of
various external modules" only works if there's no utility applications in the
outsmarted module, that are run while building the outsmarted module (cf. the
redland case in 1d028d4783). To work around that,
pass in an LD_LIBRARY_PATH (or equivalent) that finds the relevant libs as built
in that module.
(And gb_Helper_extend_ld_path was until now only available in com_GCC_defs.mk.
There, it accepts any number of paths separated by ":". When used in a
platform-independend way like it is used here, it will only support a single
path.)
Change-Id: Ic615e436b19b8b9aa7daa019c8f5287de90c3abc
The ../../../program/ links in the URE jar Class-Paths are a temporary kludge
(and juh.jar had lacked adaption for Mac OS X).
Change-Id: I2542d8a582866485dd61c05df3fc6b4b39a8403d
David Tardon