...after 945c10f42f "upload harfbuzz 1.6.3" had
dropped it completely. Still necessary to e.g. avoid "runtime error: index 3
out of bounds for type 'OT::LongMetric const[1]'" during CppunitTest_emfio_wmf.
Change-Id: Idd93f6224f7e43016a71678bcaf5cc0527f95cee
...after 5aab2900df "tdf#109142: Update to
HarfBuzz 1.4.8". The parts that were still relevant for 'make check' are:
* 6694ce6b54 "external/harfbuzz: Work around ASan
out of bounds warning"
* 99f7aacd5b "external/harfbuzz:
-fsanitize=function"
* ca9a08bbf7 "external/harfbuzz: Silence
-fsanitize=nonnull-attribute" (plus 83a9c8e046
"build fix")
Change-Id: Ibff2a7c52c5de60ae00744acd2ef481bbb08706c
Should fix the Tibetan long U issue.
Also reverts this commit as depending on auto-detection for a required
feature is not a very good idea. The underlying issue is fixed upstream:
commit 5985bed176
Author: jan Iversen <jani@libreoffice.org>
Date: Mon Jun 12 14:51:42 2017 +0200
iOS, harfbuzz libcoretext not found
changed --with-libcoretext
from "yes" to "auto" for IOS and MACOSX
which seems to be a misguided attemp to fix the build breakage
introduced in:
commit b3559e5c6c
Author: jan Iversen <jani@libreoffice.org>
Date: Sun Jun 11 19:35:53 2017 +0200
iOS, patch harfbuzz
Add support for arm64
Also had to drop ubsan.patch as it no longer applies, hopefully it is no
longer needed, otherwise it is always good idea to submit such patches
upstream.
Change-Id: I91643c542c0a5a00f36d5564052787eedef8c9cf
Reviewed-on: https://gerrit.libreoffice.org/41124
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Michael Stahl <mstahl@redhat.com>
Also regenerated all patches using make icu.genpatch (hence the .1
suffix that indicates the path level) as some hunks did not apply anyway
and all now have the correct offset. Using genpatch may have the future
benefit to yield smaller diffs between different versions of patches.
Also prefixed all patch names with icu4c- for a cleaner listing.
New patches introduced are prefixed with icu4c-59-...
Change-Id: Ia83754b0823839887fce1a1d4ed04f8375b113c2
Reviewed-on: https://gerrit.libreoffice.org/36809
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Eike Rathke <erack@redhat.com>
When libtool links a library with another libtool-based library, it
replaces -lfoo by path to installed foo, like $foo-libdir/libfoo.la.
harfbuzz would be installed to /usr/local/lib by default, therefore
libtool replaces -lharfbuzz by /usr/local/lib/libharfbuzz.la in
libfreetype.la, which causes a failure (nonexistent file) when building
fontconfig...
Change-Id: Ie2510034e69803af084dd90671fdbc8f6863fcf2
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
* 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>
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>
Should fix crashes due to symbol clashes in ELF global namespace
where system's libharfbuzz.so.0 is loaded as well.
Change-Id: I35ffcbe4ac4de5a25cd8bf0cb9a8f0c11f4554c5
Most of ubsan.patch seems to have been applied upstream, and I can’t
reproduce the issue referenced for the remaining bits, anyway it is
better to push such changes upstream first.
Change-Id: Ie56786c01c06d3542052cd91e36d1f707092beba
Reviewed-on: https://gerrit.libreoffice.org/15643
Tested-by: Jenkins <ci@libreoffice.org>
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
Tested-by: Caolán McNamara <caolanm@redhat.com>
Seems that when cross-compiling to Android from Linux, we apparently
have used either the build platform's pkg-config files for ICU, or the
build platform's icu-config. Both of which are obviously the wrong
thing to do, but apparently it has worked by accident anyway.
This makes building for Android on OS X proceed past harfbuzz, at least.
Change-Id: I27351f6177438697a1cded642c8c669ba7221009
Stephan Bergmann