...as stoc/Library_javavm.mk depends on it since
9b09a217c79e8a35fc4de54c89ef49fbf8f72752 "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>
The code in harfbuzz' src/hb_common.h apparently goes to some length to ensure
that any value of type hb_tag_t (aka unit32_t) can be transported as a value of
the hb_script_t enum type. However, under MSVC any C (or non-fixed C++) enum
type has an underlying type of int, so _HB_SCRIPT_MAX_VALUE of value 0xFFFFFFFF
will cause a -Wmicrosoft-enum-value under clang-cl. To not complicate things
further, acknowledge that converting between hb_tag_t (an unsigned integer type
with 32 value bits) and hb_script_t (a two's-complement signed integer type with
32 value bits) is well-defined under MSVC and drop _HB_SCRIPT_MAX_VALUE (which
appears to be an otherwise unused implementation detail) there.
Change-Id: Ic03dff64a9dd24683c45347fa78699708c269972
Harfbuzz will now need to be built with Graphite support. This allows
Harfbuzz to handle Graphite fonts. In case we all building with
system Harfbuzz, then it should be built with Graphite support else
we error out.
Change-Id: I156ec08b9e5ad7ce87cc15e4b5852d9c57c98f7f
* There's an --enable-developer configure option, but it probably does more than
just default to the "Debug" target, things we potentially don't want here.
* Disabling --enable-debug for MSC was apparently a leftover from firebird 2
times, f58f10fc89e19d182b5a415bb69af5ecc7de080a "firebird: --enable-debug
breaks the build with MSVC".
Change-Id: Id9f7b6aa0cdfcea0b07f94814a8dab43488879bb
Currently LFS_CFLAGS are only used in a handful of libraries but there's
no obvious reason why it can't just be set everywhere.
Also set it in windows.mk, i have no idea if it's needed for MinGW
(certainly not for MSVC).
Change-Id: I5f62e3011c2089abbf5539fc54c7ff10e07b1599
* Only build the library, makes no-freetype patch redundant.
* Don’t build ICU support as a separate library, otherwise we would also
build the alternative UCDN Unicode functions which we do not use.
* Don’t build FontConfig support stuff that was added a few releases ago
as we don’t need it as well.
Change-Id: Ia5f296c61a6ce2a589b1c521b3c2c7c75dbcf74d
Reviewed-on: https://gerrit.libreoffice.org/29342
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 ecd5d49dc30d11845ccc1a14e26bf37d73959463 "liblangtag: prevent libtool
from adding annoying stuff to RPATH". "Outsmarting" libtool in the way
described in 1d028d4783da69c5c0e6e0b59e0f8ac55eb9d2b1 "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 1d028d4783da69c5c0e6e0b59e0f8ac55eb9d2b1). 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
libpython3.so is the "ABI compatible" wrapper library around
libpython3.5m.so - it is not actually used by anything in LO right now,
but let's ensure it has RPATH $ORIGIN just in case.
This revealed that the AIX patch in python3 accidentally changed the
SONAME of libpython3.5m.so from upstream's libpython3.5m.so.1.0
on ELF platforms, because the SONAME variable was set in the shell
command but read as a make variable in the next line, which is actually
evaluated earlier.
So rename a few files in packages to use the upstream SONAME.
Change-Id: I3611f75eee62b0993b853230521a2fa41ac5cd9c
* 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>
...whose (static) library is called "zlib" instead of just "z".
(I ran into this when trying to do a 32-bit Linux build in a 64-bit environment,
with only very limited 32-bit support installed in the system.)
Change-Id: I9286975917ddf643a22803561677af035e66fb98
Reviewed-on: https://gerrit.libreoffice.org/28964
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
In external/harfbuzz/ExternalProject_harfbuzz.mk we are careful to configure
harfbuzz --with-freetype=no, but then harfbuzz goes on to nevertheless link some
of its programs against freetype. However, those all appear to be test programs
that we do not otherwise rely on, so just suppress building them in the first
place.
(I ran into this when trying to do a 32-bit Linux build in a 64-bit environment,
with only very limited 32-bit support installed in the system.)
Change-Id: I1bab2ff4b533e5a30d68d72ec001904cb63f5d94
Reviewed-on: https://gerrit.libreoffice.org/28963
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
Tested-by: Stephan Bergmann <sbergman@redhat.com>
...where the 10.12 SDK includes clock_gettime, marked as
__attribute__((availability(macosx,introduced=10.12)))
in time.h. However, the way firebird's configure checks for it, it gets
detected as available regardless of the used -mmacosx-version-min value (and
even if the configure check would go via the time.h header, the availability
attribute would only cause a -Wpartial-availability warning, not an error, so
we'd need to pass CFLAGS=-Werror=partial-availability into firebird's
configure.)
Change-Id: I67e12743e1df0574e7fc4b2121add9fe1fb7677b
Since 77104ccd7658cb8f3ac142ea9f7fabc15fc08580 the OxygenOffice
distro configs are removed and no other official distro uses these.
Change-Id: I2b4d5fea7e4b9098ac88733821af219db23c48fe
Reviewed-on: https://gerrit.libreoffice.org/28738
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Andras Timar <andras.timar@collabora.com>
- drop rasqal-pkgconfig.patch.1:
merged upstream
- drop most of rasqal-msvc.patch.1:
merged upstream
- drop redland-query-rasqal-avoid-assert.patch.1:
merged upstream
- drop redland-pkgconfig.patch.1:
merged upstream
Change-Id: I4f03bed5fc5c4b30151c0c532572e438681da041
Reviewed-on: https://gerrit.libreoffice.org/28416
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
