Linking libxml2 against ICU libraries has a nasty side effect:
The URE library javavm.dll links against URE libxml2.dll, which
is now linked against OOO icuuc53.dll; when a URE program, like
uno.exe, tries to load javavm.dll it fails because the OOO layer
"program" dir is not on PATH; this breaks the installation of Java
extensions.
Fix that by splitting up ICU libraries and putting the required ones
into URE layer.
(regression from 7515b1a90fac9e31733c0fdcc1156adadf0e6f99)
Change-Id: If98dd0357162cb632d9762cd2d20162de5eb1a52
...so that -fsanitize=undefined does not report false out-of-bounds accesses;
Clang's isFlexibleArrayMemberExpr (lib/CodeGen/CGExpr.cpp) only treats arrays of
length 0 and 1 as such special flexible cases.
There appears to be no code in icu that depends on those arrays to be of length
2 (e.g., via sizeof), though it does look suspicious that they are deliberately
of length 2 instead of 1.
Change-Id: I85293e769f1d64cb4e60e13f1cd7f88b76e37487
plus further work in i18npool to make that build
adapt i18npool to ICU 53 upgrade, fdo#77071
Korean charset collator can't be built from ko_charset.txt because of
"The runtime code decomposes Hangul syllables on the fly, with recursive
processing but without making the Jamo pieces visible for matching. It
does not work with certain types of contextual mappings."
"While handling a Hangul syllable, contractions starting with Jamo L or
V would not see the following Jamo of that syllable." (this is where we
bail out already with the first syllable of ko_charset.txt)
Another condition to fail is described as "A contraction ending with
Jamo L or L+V would require generating Hangul syllables in
addTailComposites() (588 for a Jamo L), or decomposing a following
Hangul syllable on the fly, during contraction matching."
Excluded the file from the build for ICU >=53 and hope that ICU in the
mean time handles Korean collation correctly.
Additionally, ICU 53 took ages (if it would had finished at all) to
build the collator from zh_TW_charset.txt because of the \u#### escaped
notation. Converted the file's content to characters using
http://www.rishida.net/tools/conversion/
Change-Id: I64213214b4870e7077f72b95fee1ddc9782c2b21
Reviewed-on: https://gerrit.libreoffice.org/9204
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: Eike Rathke <erack@redhat.com>
Also, for some reason building the endian check thing fails when trying to use
Clang for Android, so just hardcode it.
Change-Id: I04fb7ba4f88a1dc6a4e743b39e7c0cd19d7e3598
The intent being that the data file will be used instead.
To avoid linking error, correspondingly include the ICU stubdata
library in the list of static libraries to link with.
Change-Id: I0f223fcce89dfbe283aaa2fcd2d5a58ea36ba364
for our -D__float128=void hack for Clang against libstdc++; it is OK that that
explicitly enables C++11 for ICU, as ICU's configure.ac would set -std=c++0x if
no -std= is passed in.
Change-Id: I0e5044773c3d6923e3b100e19b5b54ab9edf7a1b
- WORKDIR path is just workdir
- INSTDIR path is just instdir
- WORKDIR_FOR_BUILD is workdir_for_build
- INSTDIR_FOR_BUILD is instdir_for_build
- replace other usage of INPATH by combination of OS and CPUNAME
Change-Id: Ie398387ebd82a968ec2605f2103c55b43a231482
Reviewed-on: https://gerrit.libreoffice.org/6601
Reviewed-by: Tor Lillqvist <tml@collabora.com>
Tested-by: Tor Lillqvist <tml@collabora.com>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
It is constant and can just be replaced by $(SRCDIR)/solenv.
Use BUILD_TYPE where it was used to check if config_*.mk is sourced.
Change-Id: Ib9d480c57194b6340093aa47776f8768df69b7d1
