summaryrefslogtreecommitdiff
path: root/external/harfbuzz
AgeCommit message (Collapse)AuthorFilesLines
12 hoursharfbuzz: create symbols with --enable-symbolsChristian Lohmaier1-1/+2
--enable-symbols can be used independently (and selectively) from --enable-debug or --enable-dbgutil, so if neither of those are specified, check whether symbols should be created and pass the flags to c_args / cpp_args Change-Id: I6d5bc9b7857a2538b71efb820534c2a18d1dfd3e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184753 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
12 hoursfix harfbuzz with --enable-debug on win (msvc debug runtime mismatch)Christian Lohmaier1-1/+1
debug type in meson uses flags to use debug versions of the vscrt, this causes issues when using --enable-debug since the rest of the build only uses the debug runtime if the --enable-dbgutil switch is used. These two being misaligned then causes linker failures, harfbuzz using the debug runtime and rest of LO using the release version is not compatible: libharfbuzz.a(hb-blob.cc.obj) : error LNK2038: mismatch detected for 'RuntimeLibrary': value 'MDd_DynamicDebug' doesn't match value 'MD_DynamicRelease' in drawmode.o the debugoptimized build-type doesn't use the debug runtime and also uses optimization flags that don't interfere with debugging. The runtime could also be forced independently using -Db_vscrt=<mdd,md,mtd,mt>, but the automatic selection from the buildtype/the additional optimization in the --enable-debug case should be fine. Change-Id: I9263fa7b6fdb71ab9efb00ae634ddf16453e50cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184751 Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Reviewed-by: Olivier Hallot <olivier.hallot@libreoffice.org> Tested-by: Olivier Hallot <olivier.hallot@libreoffice.org> Tested-by: Jenkins
16 hoursharfbuzz: Honor USE_LD, don't force specific linker if unsetMichael Weghorn1-5/+8
With the harfbuzz build having been switched to meson in commit commit ae24fc8c639b230284f94e837497cd7919f79d21 Date: Tue Apr 8 12:19:31 2025 +0200 harfbuzz: migrate to meson , building harbuzz in my local Android build using an autogen.input containing --with-android-ndk=$HOME/Android/Sdk/ndk/28.0.13004108 --with-android-sdk=$HOME/Android/Sdk --with-distro=LibreOfficeAndroidX86_64 --enable-sal-log --enable-android-editing --with-external-tar=/home/michi/development/libreoffice-external --disable-ccache --with-jdk-home=/usr/lib/jvm/java-21-openjdk-amd64/ started to fail because it couldn't detect the linker to use. This is caused by `c_ld` and `cpp_ld` explicitly being set to the *compiler* command in `cross-file.txt` that meson evaluates which is then used by meson to set the *linker* to use via `-fuse-ld=<command>` for gcc or clang (see [1]). However, ccache or clang are not suitable to be used as linkers. Fix that problem by evaluating the USE_LD variable and using the linker set this way. (It is `USE_LD=-fuse-ld=lld` for above-mentioned Android build.) If it's not set, then having an empty `c_ld` and `cpp_ld` is fine and will result in no particular linker being forced, i.e. let meson use its default logic. Leaving it empty is also fine on Windows. Quoting Christian Lohmaier's comment [2]: > re windows: linker can be empty, it then would try link from the vsenv, > but for static libraries it defaults to using LIB / so in the case > for harfbuzz c_ld / cpp_ld are in fact ignored/unused. for this case > ar setting would be used to override. Also, replace "X86_64" by "x86_64" for the `cpu_family` to address the WARNING: Unknown CPU family X86_64, please report this at https://github.com/mesonbuild/meson/issues/new warning seen in the below output. Thanks to Christian Lohmaier on whose feedback on earlier versions of the Gerrit change this is heavily based! --------------------------------------------------------- Error seen previously with an `--enable-ccache` build, where `-fuse-ld=/usr/bin/ccache` would be used: $ make harfbuzz cd /home/michi/development/git/libreoffice-WORKTREE-android/external/harfbuzz && make -j 32 -rs [LOC] top level modules: harfbuzz WARNING: Unknown CPU family X86_64, please report this at https://github.com/mesonbuild/meson/issues/new The Meson build system Version: 1.7.0 Source dir: /home/michi/development/git/libreoffice-WORKTREE-android/workdir/UnpackedTarball/harfbuzz Build dir: /home/michi/development/git/libreoffice-WORKTREE-android/workdir/UnpackedTarball/harfbuzz/builddir Build type: cross build Project name: harfbuzz Project version: 11.0.1 meson.build:1:0: ERROR: Unable to detect linker for compiler `/usr/bin/ccache /home/michi/Android/Sdk/ndk/28.0.13004108/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -target x86_64-linux-android21 -no-canonical-prefixes -ffunction-sections -fdata-sections -Qunused-arguments -Wl,--version -fuse-ld=/usr/bin/ccache` stdout: stderr: /usr/bin/ccache: unrecognized option '--hash-style=both' clang: error: linker command failed with exit code 1 (use -v to see invocation) [...] --------------------------------------------------------- Error seen previously with a `--disable-ccache build`, where `-fuse-ld=/home/michi/Android/Sdk/ndk/28.0.13004108/toolchains/llvm/prebuilt/linux-x86_64/bin/clang` would be used: $ make harfbuzz cd /home/michi/development/git/libreoffice-WORKTREE-android/external/harfbuzz && make -j 32 -rs [LOC] harfbuzz [UPK] harfbuzz-11.0.1.tar.xz [LOC] top level modules: harfbuzz [PAT] harfbuzz WARNING: Unknown CPU family X86_64, please report this at https://github.com/mesonbuild/meson/issues/new The Meson build system Version: 1.7.0 Source dir: /home/michi/development/git/libreoffice-WORKTREE-android/workdir/UnpackedTarball/harfbuzz Build dir: /home/michi/development/git/libreoffice-WORKTREE-android/workdir/UnpackedTarball/harfbuzz/builddir Build type: cross build Project name: harfbuzz Project version: 11.0.1 meson.build:1:0: ERROR: Unable to detect linker for compiler `/home/michi/Android/Sdk/ndk/28.0.13004108/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -target x86_64-linux-android21 -no-canonical-prefixes -ffunction-sections -fdata-sections -Qunused-arguments -Wl,--version -fuse-ld=/home/michi/Android/Sdk/ndk/28.0.13004108/toolchains/llvm/prebuilt/linux-x86_64/bin/clang` stdout: Android (12896553, +pgo, +bolt, +lto, +mlgo, based on r530567c) clang version 19.0.0 (https://android.googlesource.com/toolchain/llvm-project 97a699bf4812a18fb657c2779f5296a4ab2694d2) Target: x86_64-unknown-linux-gnu Thread model: posix InstalledDir: /home/michi/Android/Sdk/ndk/28.0.13004108/toolchains/llvm/prebuilt/linux-x86_64/bin stderr: clang: error: unknown argument: '--hash-style=both' clang: error: unknown argument: '--eh-frame-hdr' clang: error: unknown argument: '-m' clang: error: linker command failed with exit code 1 (use -v to see invocation) [...] [1] https://mesonbuild.com/Machine-files.html#binaries [2] https://gerrit.libreoffice.org/c/core/+/184459/comments/dbb124af_3c49b1e0 Change-Id: I0793d7cc3428a13a050b5989a9e326b1b80595f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184459 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
32 hoursharfbuzz: upgrade to 11.2.0Xisco Fauli1-4/+6
Downloaded from https://github.com/harfbuzz/harfbuzz/releases/download/11.2.0/harfbuzz-11.2.0.tar.xz Change-Id: Ib9910d1a9e1a657b1d26f05354a7213d48b85e83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184761 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
5 daysInstead of warning and failing, just do the right thingStephan Bergmann1-2/+2
After df83ad933b11e973855d66792c9aff38714f9201 "fix harfbuzz build with --enable-python=fully-internal on linux", my --enable-python=fully-internal Linux builds that auto-detect MESON=/usr/bin/meson started to emit a configure warning > * WARNING : using internal python with a meson launcher might not work, best to use MESON=/path/to/meson.py in autogen.input and then fail to build ExternalProject_harfbuzz with > Traceback (most recent call last): > File "/home/sberg/lo/core/instdir/program/python-core-3.11.12/lib/importlib/metadata/__init__.py", line 563, in from_name > return next(cls.discover(name=name)) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > StopIteration > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "/usr/bin/meson", line 33, in <module> > sys.exit(load_entry_point('meson==1.7.0', 'console_scripts', 'meson')()) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/bin/meson", line 22, in importlib_load_entry_point > for entry_point in distribution(dist_name).entry_points > ^^^^^^^^^^^^^^^^^^^^^^^ > File "/home/sberg/lo/core/instdir/program/python-core-3.11.12/lib/importlib/metadata/__init__.py", line 982, in distribution > return Distribution.from_name(distribution_name) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/home/sberg/lo/core/instdir/program/python-core-3.11.12/lib/importlib/metadata/__init__.py", line 565, in from_name > raise PackageNotFoundError(name) > importlib.metadata.PackageNotFoundError: No package metadata was found for meson So better add back the idea from 736998ccef0bacdd2bbf038c98dacfbe654f1a4d "Only run meson from python when it apparently needs to be" (that had been removed with df83ad933b11e973855d66792c9aff38714f9201 "fix harfbuzz build with --enable-python=fully-internal on linux") to treat a Meson executable that doesn't advertise itself as being a Python script as just any plain executable, which we don't throw at our --enable-python=fully-internal interpreter. (Just like, say, an Emscripten build of LO uses an emcc compiler executable that internally uses Python, and onto which we don't force our --enable-python=fully-internal interpreter, either.) Change-Id: I13965ef08043f350e9614bd61a469708b7faf27b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184626 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
5 daysharfbuzz with fully-internal python: extend the chmod to all python scriptsChristian Lohmaier1-1/+1
depending on the meson version also other scripts like src/relative_to.py are run and cause the same problem (namely picking up system python instead of the python meson was run with, see description of df83ad933b11e973855d66792c9aff38714f9201 / the commend in the makefile for more details Change-Id: I2c75d9a12455495174be7c53a1cca5d5a8f45f8e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184622 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
9 daysfix harfbuzz build with --enable-python=fully-internal on linuxChristian Lohmaier2-2/+9
if executable python scripts are run as build commands, they can pick up system python instead of the LO-internal python and that then can cause incompatibilities, ranging from just being too old and failing with stuff like AttributeError: 'str' object has no attribute 'isascii' or attempting to load incompatible modules […] from . import _compiler, _parser File "/home/michi/development/git/libreoffice/instdir/program/python-core-3.11.12/lib/re/_compiler.py", line 18, in <module> assert _sre.MAGIC == MAGIC, "SRE module mismatch" AssertionError: SRE module mismatch So remove the executable bit to make sure the scripts are run with the python specified for the build, either internal or the system one. Also undo the workaround added in 736998ccef0bacdd2bbf038c98dacfbe654f1a4d (Only run meson from python when it apparently needs to be) While this can help running meson itself if the distro has different python versions but cannot be run with the default python3 / the python version used to run meson is likely newer and then also avoids most of the issues above, it still is bad to mix build-tool python and the commands executed by the buildtool. For the cornercase of meson not being able to be executed by the python used for the build, the solution is to either specify PYTHON=/hatever/python/system/meson/uses (for the non-fully-internal case) and/or using a release tarball of meson and pointing MESON=/path/to/meson.py in autogen.input (can be used with both system and internal python) Change-Id: Id8e3ea88e0caa4afa872a62207b081c072496903 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184271 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2025-04-16Only run meson from python when it apparently needs to beStephan Bergmann1-2/+2
...where "apparently needs to be" is approximated by the meson executable being named *.py (which, in turn is approximated by some GNU Make $(filter) check). This follows up on ae24fc8c639b230284f94e837497cd7919f79d21 "harfbuzz: migrate to meson" and should avoid e.g. issues with --enable-python=fully-internal on Linux like > Traceback (most recent call last): > File "/home/sberg/lo/core/instdir/program/python-core-3.11.12/lib/importlib/metadata/__init__.py", line 563, in from_name > return next(cls.discover(name=name)) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > StopIteration > > During handling of the above exception, another exception occurred: > > Traceback (most recent call last): > File "/usr/bin/meson", line 33, in <module> > sys.exit(load_entry_point('meson==1.7.0', 'console_scripts', 'meson')()) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/usr/bin/meson", line 22, in importlib_load_entry_point > for entry_point in distribution(dist_name).entry_points > ^^^^^^^^^^^^^^^^^^^^^^^ > File "/home/sberg/lo/core/instdir/program/python-core-3.11.12/lib/importlib/metadata/__init__.py", line 982, in distribution > return Distribution.from_name(distribution_name) > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > File "/home/sberg/lo/core/instdir/program/python-core-3.11.12/lib/importlib/metadata/__init__.py", line 565, in from_name > raise PackageNotFoundError(name) > importlib.metadata.PackageNotFoundError: No package metadata was found for meson > make[1]: *** [/home/sberg/lo/core/external/harfbuzz/ExternalProject_harfbuzz.mk:47: /home/sberg/lo/core/workdir/ExternalProject/harfbuzz/build] Error 1 (<https://gerrit.libreoffice.org/c/core/+/183345/22#message-66c17b20610944c79d6d7206a62869ad430c3a60> "harfbuzz: migrate to meson") Change-Id: I44da7aebdc35a4be838046f0b065f1b646487156 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184254 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de> Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2025-04-14tdf#161981, tdf#157922, tdf#163892 Upgrade HarfBuzz to 11.0.1Khaled Hosny1-3/+3
Downloaded from https://github.com/harfbuzz/harfbuzz/releases/tag/11.0.1 Change-Id: Id3a6c2c54dde2530ced66a7f971a23aa2fdb815f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184176 Reviewed-by: Khaled Hosny <khaled@libreoffice.org> Tested-by: Jenkins
2025-04-14harfbuzz: migrate to mesonChristian Lohmaier3-120/+39
Change-Id: I33aa7ca814409b39b9adb7da1d168c5ebb11b14d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183345 Reviewed-by: Khaled Hosny <khaled@libreoffice.org> Tested-by: Jenkins
2024-09-13ICU: fix aclocal dependencyXisco Fauli2-13/+79
Patch configure directly instead of configure.ac Change-Id: Iaaf3e10dc435d5d8f546c009b27c9a4aa7c09141 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173315 Tested-by: Jenkins Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-09-12ICU: upgrade to 75.1Xisco Fauli2-0/+23
Downloaded from https://github.com/unicode-org/icu/releases/tag/release-75-1 Change-Id: I882c57bf5ab613dc71f7ae1c31305596e1ca791f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/168750 Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Tested-by: Jenkins Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
2024-05-06makefile simplification: replace $(call gb_UnpackedTarball_get_dir,foo)Christian Lohmaier1-1/+1
…by a simple/static $(gb_UnpackedTarball_workdir)/foo see also 0c4c84a14b01c71c76a9c45a7f26aec4d64f3e4f Change-Id: I8e6aa55c85534c4446556548910c950ddbe7c6fc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/167163 Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> Tested-by: Jenkins
2024-02-21tdf#159529 clear hb_ot_face_t data after fetching 'sbix' and 'glyf' tablesPatrick Luby2-0/+29
The 'sbix' and 'glyf' tables can be very large for color emoji fonts so clear any cached data in hb_ot_face_t after fetching that table's extents. Change-Id: Id5deda9114b7199a4194ff16879e5791acd1cd82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163674 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-07-12Upgrade Harfbuzz to 8.0.0Taichi Haradaguchi2-18/+0
Change-Id: I04d81509c50f0335d201b5286460989f526b58f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154233 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2023-07-08tdf137553: Fix advance width for text using Graphite fontsKhaled Hosny2-0/+18
This is a HarfBuzz bug and it was reported upstream. Change-Id: Ibf945d30f57c7fb847b63c40f5a7b2903958ab89 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/154213 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-07-01Upgrade Harfbuzz to 7.3.0Taichi Haradaguchi1-1/+5
Release Notes: https://github.com/harfbuzz/harfbuzz/releases/tag/7.2.0 (v7.2.0) https://github.com/harfbuzz/harfbuzz/releases/tag/7.3.0 (v7.3.0) Change-Id: I4f57b7e829f2356b5e2b442ff00df555121c0e66 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153729 Tested-by: Taichi Haradaguchi <20001722@ymail.ne.jp> Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2023-06-21No need to fiddle with ICU UChar typedef anymoreKhaled Hosny1-1/+0
The affected external dependencies should be building with c++11 by now already. Change-Id: I0d1f8aed6ed28f510f456a368b724c3c4eeb3240 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/153389 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@libreoffice.org>
2023-03-23Upgrade Harfbuzz to 7.1.0Taichi Haradaguchi1-1/+1
* Fixes CVE-2023-25193. * if Harfbuzz >= 7.0.0, uses hb_font_draw_glyph() instead of hb_font_get_glyph_shape(). * Update URL in README. Change-Id: Id234c2b459c40ddac340731b44889b104e03a1e8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148743 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com>
2023-02-22vcl: Avoid the need to patch HarfBuzzKhaled Hosny2-27/+0
Reverts parts of d552b4a549d614a03aa9328e017dec27bd3ff41e and 97e2e73e87479a742b798f362eda4baafb89497c. Instead of patching HarfBuzz, lets make use of the already mmap’ed file we use with FreeType. Change-Id: Ia81222118162a30cadb8c988bc477ad3ce36166d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147410 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2023-02-09Enable opening of downloaded fonts only in ForKit in OnlineTor Lillqvist2-0/+27
We want that only the ForKit process needs to have access to new font files added to a Collabora Online instance dynamically by downloading from a server. There are however many locations in the Kit process, in core and in external libraries like harfbuzz, where the code wants to open a font file. Handle this so that the ForKit process opens such a downloaded font file and doesn't close it. The file descriptor is thus inherited by Kit processes. The font file pathname passed on to other code is a fake on in the format "/:FD:/%d" where the %d is the file descriptor of the opened font file. Add checks in all places where font files are opened, look for this special pathname format, and modify the code to just dup() the already open file descriptor in that case. All this is relevant for Linux only, as Collabora Online runs on Linux. Do the above for harfbuzz, cairo, fontconfig, and freetype. In addition make sure that these libraries (except harfbuzz which needs to be a static library and freetype) when bundled, on Linux, are built as shared libraries, and won't be confused with the corresponding system libraries by making sure their sonames are different. Change-Id: Ib059cb27e1637d07bb709249abd0d984f948caa9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/140714 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146341 Tested-by: Jenkins
2022-12-17Update HarfBuzz to 6.0.0Khaled Hosny6-313/+0
Change-Id: Id371a53a126f2b95b17e642a9c63adafd5aa3d33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144394 Tested-by: Jenkins Reviewed-by: خالد حسني <khaled@aliftype.com>
2022-11-25add in latest harfbuzz effortCaolán McNamara2-0/+63
the document still fails for me, but in a new way which suggests a possible problem on our side. Change-Id: Ic38259653a43b39f9330adc503d085a896c15d2a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143246 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-11-24backport recent libreoffice-related harfbuzz fixesCaolán McNamara4-0/+201
Change-Id: I1ff1b6291e9799d95477334f2726132ddc99442f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143208 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-11-17use harfbuzz upstream fix instead of workaroundCaolán McNamara2-0/+52
drop temp workaround for problem seen with tdf119074-1.odt i.e. apply https://github.com/harfbuzz/harfbuzz/pull/3874 for https://github.com/harfbuzz/harfbuzz/issues/3824 Change-Id: I42373f2282d30d7e45ee88b654d3df40f3a6384b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/142815 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-07-31Update HarfBuzz to 5.1.0Khaled Hosny2-18/+0
Dropping negativeadvance.patch that was applied upstream. Change-Id: I8eba49d2d158c0c29911f4079315ed0bf87b7fa6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137648 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-05-01try to use also proper debug LDFLAGS for externals librariesLuboš Luňák1-0/+1
This is basically ea68de2968c0dbcd8e7549435e829db06795c16d but for LDFLAGS. A number of external libs cannot use this because their libtool mishandles -fuse-ld. Change-Id: Idee379eb0a3afb475b536519ee3de064b4e218f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133639 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-04-12use gb_DEBUGINFO_FLAGS consistently in gbuild ExternalProject'sLuboš Luňák1-3/+1
A number of them didn't use it at all, others had it hand-written in various ways. Change-Id: Iaf86325f9cdc032926bac917dc3eef4e34661544 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/132818 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-01-31externals: always provide platform configure flagsJan-Marek Glogowski1-1/+1
No idea why we just provided the platform flags when cross- compiling. In the curious case, where the host platform is detected as x86_64-pc-mingw32 per default and we actually want to override it with x86_64-pc-cygwin, we don't do a cross compile, but must override the host platform. But there is additional special handling needed for the omitted cross-platform build in the special case of --host=i686-pc-cygwin and --build=x86_64-pc-cygwin, where we deliberatly ignore cross building; Windows is already a slow build, so try to keep this optimization (AMD64 can execute x86 binaries). There is the theoretical case, where the externals config.guess would have detected something else and that "magically" even worked, while the LO detected triplet would fail, but this should be fixed in the external in any way. Change-Id: Ib7a9719e0e406fe90334b7611dc3f01b51692bfa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/129153 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-08-10Mark external/harfbuzz/negativeadvance.patch as sent upstreamStephan Bergmann1-0/+3
Change-Id: Ia12ea1fce7a994b519e743edbc18cbd27ccb78bd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120210 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-09external/harfbuzz: hb_graphite2_cluster_t::advance can apparently be negativeStephan Bergmann2-0/+15
...as seen with `instdir/program/soffice --headless --convert-to pdf` of doc/abi6073-2.doc from the crash-testing corpus when run under UBSan, > hb-graphite2.cc:361:15: runtime error: -1024 is outside the range of representable values of type 'unsigned int' > #0 in _hb_graphite2_shape at workdir/UnpackedTarball/harfbuzz/src/hb-graphite2.cc:361:15 > #1 in _hb_shape_plan_execute_internal(hb_shape_plan_t*, hb_font_t*, hb_buffer_t*, hb_feature_t const*, unsigned int) at workdir/UnpackedTarball/harfbuzz/src/./hb-shaper-list.hh:38:1 > #2 in hb_shape_plan_execute at workdir/UnpackedTarball/harfbuzz/src/hb-shape-plan.cc:453:14 > #3 in hb_shape_full at workdir/UnpackedTarball/harfbuzz/src/hb-shape.cc:139:19 > #4 in GenericSalLayout::LayoutText(ImplLayoutArgs&, SalLayoutGlyphsImpl const*) at vcl/source/gdi/CommonSalLayout.cxx:495:23 > #5 in OutputDevice::getFallbackLayout(LogicalFontInstance*, int, ImplLayoutArgs&, SalLayoutGlyphs const*) const at vcl/source/outdev/font.cxx:1232:21 > #6 in OutputDevice::ImplGlyphFallbackLayout(std::unique_ptr<SalLayout, std::default_delete<SalLayout> >, ImplLayoutArgs&, SalLayoutGlyphs const*) const at vcl/source/outdev/font.cxx:1300:48 > #7 in OutputDevice::ImplLayout(rtl::OUString const&, int, int, Point const&, long, long const*, SalLayoutFlags, vcl::TextLayoutCache const*, SalLayoutGlyphs const*) const at vcl/source/outdev/text.cxx:1332:22 > #8 in lcl_CreateLayout(SwTextGlyphsKey const&, __gnu_debug::_Safe_iterator<std::_Rb_tree_iterator<std::pair<SwTextGlyphsKey const, SwTextGlyphsData> >, std::__debug::map<SwTextGlyphsKey, SwTextGlyphsData, std::less<SwTextGlyphsKey>, std::allocator<std::pair<SwTextGlyphsKey const, SwTextGlyphsData> > >, std::bidirectional_iterator_tag>) at sw/source/core/txtnode/fntcache.cxx:233:33 > #9 in SwFntObj::GetCachedSalLayoutGlyphs(SwTextGlyphsKey const&) at sw/source/core/txtnode/fntcache.cxx:257:12 > #10 in SwFont::GetTextBreak(SwDrawTextInfo const&, long) at sw/source/core/txtnode/fntcache.cxx:2551:58 > #11 in SwTextSizeInfo::GetTextBreak(long, o3tl::strong_int<int, Tag_TextFrameIndex>, unsigned short, vcl::TextLayoutCache const*) const at sw/source/core/text/inftxt.cxx:450:20 > #12 in SwTextGuess::Guess(SwTextPortion const&, SwTextFormatInfo&, unsigned short) at sw/source/core/text/guess.cxx:205:26 > #13 in SwTextPortion::Format_(SwTextFormatInfo&) at sw/source/core/text/portxt.cxx:305:32 > #14 in SwTextPortion::Format(SwTextFormatInfo&) at sw/source/core/text/portxt.cxx:456:12 > #15 in SwLineLayout::Format(SwTextFormatInfo&) at sw/source/core/text/porlay.cxx:260:31 (where in frame #4 GenericSalLayout::LayoutText, pHbBuffer->props.direction is HB_DIRECTION_RTL, in case that is relevant). It is unclear to me whether it is sufficient to only change hb_graphite2_cluster_t::advance from signed to unsigned int, as there are other unsigned int variables (like curradv in _hb_graphite2_shape) whose value depend on hb_graphite2_cluster_t::advance, and which thus might also become negative. But unlike the float -> unsigned int conversion that UBSan warned about here (where gr_slot_origin_X() and xscale are float), those are signed int -> unsigned int conversions that do not cause undefined behavior. At least, with this change, the above --convert-to pdf and a full `make check screenshot` succeeded for me under without further UBSan warnings. Change-Id: Ifa6fa930da162b986d3f536f8b3613790b3f19c8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120192 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-07-20tdf#143429: update harfbuzz to 2.8.2 versionJulien Nabet4-56/+0
Change-Id: I263dc6da5be3ea55205076a1f4e263fe5bba31fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119232 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2021-06-28Mark external/harfbuzz/Wunused-but-set-variable.patch as fixed upstreamStephan Bergmann1-0/+4
Change-Id: Iefc8f4f6ff93ec1a11256724b1881689d5eb56d9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117992 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-06-25Silence -Werror,-Wunused-but-set-variable (clang-cl 13 trunk)Stephan Bergmann2-0/+13
...during build of ExternalProject_harfbuzz: > In file included from hb-ot-shape-complex-myanmar.cc:136: > hb-ot-shape-complex-myanmar-machine.rl(108,36): error: variable 'act' set but not used [-Werror,-Wunused-but-set-variable] > unsigned int p, pe, eof, ts, te, act HB_UNUSED; > ^ Change-Id: Ie75a5cfa16c29c02e1b97380ebd63e7d789926f9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117850 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-05-05WASM: add initial support for Emscripten cross buildJan-Marek Glogowski1-1/+1
- configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák1-0/+2
See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-10-30Upgrade to ICU 65.1Eike Rathke2-0/+15
sberg says: On Windows, implicit --enable-extras first causes a build breaker in workdir/UnpackedTarball/icu/source/extras/scrptrun when linking, because Windows link.exe doesn't understand -o. But even with a patch > --- source/extra/scrptrun/Makefile.in > +++ source/extra/scrptrun/Makefile.in > @@ -74,7 +74,7 @@ > && CONFIG_FILES=$(subdir)/$@ CONFIG_HEADERS= $(SHELL) ./config.status > > $(TARGET) : $(OBJECTS) > - $(LINK.cc) -o $@ $^ $(LIBS) > + $(LINK.cc) $(OUTOPT)$@ $^ $(LIBS) > $(POST_BUILD_STEP) > > invoke: linking would still fail with a missing ../../lib/icuucdd.lib, which is apparently expanded from $(LIBS) there, but I have no idea where it should be built but isn't. Lets hope that --disable-extras is sufficient for our needs. Change-Id: I6d0117b230caa41abf488fcd069028e3474700f8 Reviewed-on: https://gerrit.libreoffice.org/81632 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-23external/harfbuzz: Avoid UBSan nullptr-with-nonzero-offsetStephan Bergmann2-0/+24
...(new with Clang 10 trunk), as seen during CppunitTest_emfio_emf: > hb-ot-layout-gsubgpos.hh:390:20: runtime error: applying non-zero offset 2 to null pointer > #0 in OT::hb_ot_apply_context_t::skipping_iterator_t::next() at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gsubgpos.hh:390:20 > #1 in OT::PairPosFormat1::apply(OT::hb_ot_apply_context_t*) const at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gpos-table.hh:910:22 > #2 in bool OT::hb_get_subtables_context_t::apply_to<OT::PairPosFormat1>(void const*, OT::hb_ot_apply_context_t*) at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gsubgpos.hh:625:23 > #3 in OT::hb_get_subtables_context_t::hb_applicable_t::apply(OT::hb_ot_apply_context_t*) const at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gsubgpos.hh:643:62 > #4 in OT::hb_ot_layout_lookup_accelerator_t::apply(OT::hb_ot_apply_context_t*) const at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gsubgpos.hh:2624:24 > #5 in apply_forward(OT::hb_ot_apply_context_t*, OT::hb_ot_layout_lookup_accelerator_t const&) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-layout.cc:1811:24 > #6 in void apply_string<GPOSProxy>(OT::hb_ot_apply_context_t*, GPOSProxy::Lookup const&, OT::hb_ot_layout_lookup_accelerator_t const&) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-layout.cc:1864:11 > #7 in void hb_ot_map_t::apply<GPOSProxy>(GPOSProxy const&, hb_ot_shape_plan_t const*, hb_font_t*, hb_buffer_t*) const at workdir/UnpackedTarball/harfbuzz/src/hb-ot-layout.cc:1910:7 > #8 in hb_ot_map_t::position(hb_ot_shape_plan_t const*, hb_font_t*, hb_buffer_t*) const at workdir/UnpackedTarball/harfbuzz/src/hb-ot-layout.cc:1933:3 > #9 in hb_ot_shape_plan_t::position(hb_font_t*, hb_buffer_t*) const at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:266:9 > #10 in hb_ot_position_complex(hb_ot_shape_context_t const*) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:951:12 > #11 in hb_ot_position(hb_ot_shape_context_t const*) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:994:3 > #12 in hb_ot_shape_internal(hb_ot_shape_context_t*) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:1065:3 > #13 in _hb_ot_shape at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:1088:3 > #14 in hb_shape_plan_execute at workdir/UnpackedTarball/harfbuzz/src/./hb-shaper-list.hh:42:1 > #15 in hb_shape_full at workdir/UnpackedTarball/harfbuzz/src/hb-shape.cc:139:19 > #16 in GenericSalLayout::LayoutText(ImplLayoutArgs&, SalLayoutGlyphs const*) at vcl/source/gdi/CommonSalLayout.cxx:463:23 > #17 in OutputDevice::ImplLayout(rtl::OUString const&, int, int, Point const&, long, long const*, SalLayoutFlags, vcl::TextLayoutCache const*, SalLayoutGlyphs const*) const at vcl/source/outdev/text.cxx:1312:36 > #18 in OutputDevice::GetTextBoundRect(tools::Rectangle&, rtl::OUString const&, int, int, int, unsigned long, long const*, SalLayoutGlyphs const*) const at vcl/source/outdev/text.cxx:2334:18 > #19 in drawinglayer::primitive2d::TextLayouterDevice::getTextBoundRect(rtl::OUString const&, unsigned int, unsigned int) const at drawinglayer/source/primitive2d/textlayoutdevice.cxx:297:26 > #20 in drawinglayer::primitive2d::TextSimplePortionPrimitive2D::getB2DRange(drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/textprimitive2d.cxx:305:63 > #21 in drawinglayer::primitive2d::getB2DRangeFromPrimitive2DReference(com::sun::star::uno::Reference<com::sun::star::graphic::XPrimitive2D> const&, drawinglayer::geometry::ViewInformation2D const&) at drawinglayer/source/primitive2d/baseprimitive2d.cxx:175:48 > #22 in drawinglayer::primitive2d::Primitive2DContainer::getB2DRange(drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/baseprimitive2d.cxx:199:36 > #23 in drawinglayer::primitive2d::MetafilePrimitive2D::create2DDecomposition(drawinglayer::primitive2d::Primitive2DContainer&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/metafileprimitive2d.cxx:51:67 > #24 in drawinglayer::primitive2d::BufferedDecompositionPrimitive2D::get2DDecomposition(drawinglayer::primitive2d::Primitive2DDecompositionVisitor&, drawinglayer::geometry::ViewInformation2D const&) const at drawinglayer/source/primitive2d/baseprimitive2d.cxx:126:17 > #25 in drawinglayer::tools::Primitive2dXmlDump::decomposeAndWrite(drawinglayer::primitive2d::Primitive2DContainer const&, tools::XmlWriter&) at drawinglayer/source/tools/primitive2dxmldump.cxx:332:38 > #26 in drawinglayer::tools::Primitive2dXmlDump::dumpAndParse(drawinglayer::primitive2d::Primitive2DContainer const&, rtl::OUString const&) at drawinglayer/source/tools/primitive2dxmldump.cxx:130:5 > #27 in (anonymous namespace)::Test::checkRectPrimitive(com::sun::star::uno::Sequence<com::sun::star::uno::Reference<com::sun::star::graphic::XPrimitive2D> > const&) at emfio/qa/cppunit/emf/EmfImportTest.cxx:80:34 > #28 in (anonymous namespace)::Test::testWorking() at emfio/qa/cppunit/emf/EmfImportTest.cxx:94:5 and similarly during CppunitTest_vcl_complextext: > hb-ot-layout-gsubgpos.hh:417:20: runtime error: applying non-zero offset 2 to null pointer > #0 in OT::hb_ot_apply_context_t::skipping_iterator_t::prev() at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gsubgpos.hh:417:20 > #1 in OT::MarkMarkPosFormat1::apply(OT::hb_ot_apply_context_t*) const at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gpos-table.hh:1541:22 > #2 in bool OT::hb_get_subtables_context_t::apply_to<OT::MarkMarkPosFormat1>(void const*, OT::hb_ot_apply_context_t*) at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gsubgpos.hh:625:23 > #3 in OT::hb_get_subtables_context_t::hb_applicable_t::apply(OT::hb_ot_apply_context_t*) const at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gsubgpos.hh:643:62 > #4 in OT::hb_ot_layout_lookup_accelerator_t::apply(OT::hb_ot_apply_context_t*) const at workdir/UnpackedTarball/harfbuzz/src/./hb-ot-layout-gsubgpos.hh:2624:24 > #5 in apply_forward(OT::hb_ot_apply_context_t*, OT::hb_ot_layout_lookup_accelerator_t const&) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-layout.cc:1811:24 > #6 in void apply_string<GPOSProxy>(OT::hb_ot_apply_context_t*, GPOSProxy::Lookup const&, OT::hb_ot_layout_lookup_accelerator_t const&) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-layout.cc:1864:11 > #7 in void hb_ot_map_t::apply<GPOSProxy>(GPOSProxy const&, hb_ot_shape_plan_t const*, hb_font_t*, hb_buffer_t*) const at workdir/UnpackedTarball/harfbuzz/src/hb-ot-layout.cc:1910:7 > #8 in hb_ot_map_t::position(hb_ot_shape_plan_t const*, hb_font_t*, hb_buffer_t*) const at workdir/UnpackedTarball/harfbuzz/src/hb-ot-layout.cc:1933:3 > #9 in hb_ot_shape_plan_t::position(hb_font_t*, hb_buffer_t*) const at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:266:9 > #10 in hb_ot_position_complex(hb_ot_shape_context_t const*) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:951:12 > #11 in hb_ot_position(hb_ot_shape_context_t const*) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:994:3 > #12 in hb_ot_shape_internal(hb_ot_shape_context_t*) at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:1065:3 > #13 in _hb_ot_shape at workdir/UnpackedTarball/harfbuzz/src/hb-ot-shape.cc:1088:3 > #14 in hb_shape_plan_execute at workdir/UnpackedTarball/harfbuzz/src/./hb-shaper-list.hh:42:1 > #15 in hb_shape_full at workdir/UnpackedTarball/harfbuzz/src/hb-shape.cc:139:19 > #16 in GenericSalLayout::LayoutText(ImplLayoutArgs&, SalLayoutGlyphs const*) at vcl/source/gdi/CommonSalLayout.cxx:463:23 > #17 in OutputDevice::ImplLayout(rtl::OUString const&, int, int, Point const&, long, long const*, SalLayoutFlags, vcl::TextLayoutCache const*, SalLayoutGlyphs const*) const at vcl/source/outdev/text.cxx:1312:36 > #18 in OutputDevice::GetTextArray(rtl::OUString const&, long*, int, int, vcl::TextLayoutCache const*, SalLayoutGlyphs const*) const at vcl/source/outdev/text.cxx:961:45 > #19 in VclComplexTextTest::testArabic() at vcl/qa/cppunit/complextext.cxx:81:32 I have no idea whether this even remotely resembles a useful fix, though. Change-Id: I7671b84374cf119e173406bc60f6631a64dfc794 Reviewed-on: https://gerrit.libreoffice.org/81400 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-26harfbuzz: follow main configure's --disable-dependency-trackingChristian Lohmaier1-0/+1
Change-Id: I5ab185ca783e0e3f637c22909e53a67119349ad7 Reviewed-on: https://gerrit.libreoffice.org/78130 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2019-08-23external/harfbuzz configure needs MAKE nowStephan Bergmann1-0/+1
...after 352924a64750bb99aec54feea3af0121603c12a8 "Update HarfBbuzz to 2.6.0", where it started to fail for me on Windows with > config.status: error: in `/cygdrive/c/lo/core/workdir/UnpackedTarball/harfbuzz': > config.status: error: Something went wrong bootstrapping makefile fragments > for automatic dependency tracking. Try re-running configure with the > '--disable-dependency-tracking' option to at least be able to build > the package (albeit without support for automatic dependency tracking). > See `config.log' for more details > make[1]: *** [C:/lo/core/external/harfbuzz/ExternalProject_harfbuzz.mk:24: C:/lo/core/workdir/ExternalProject/harfbuzz/build] Error 1 because it didn't find any `make` (I only have an /opt/lo/bin/make installed). Change-Id: I378448b2cf1c92596220b0142e4e67a83162d972 Reviewed-on: https://gerrit.libreoffice.org/77987 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-08-20Update HarfBbuzz to 2.6.0Khaled Hosny3-24/+0
Change-Id: I7983dd10fe6599a2473caf0da04a0df3e63e9b2a Reviewed-on: https://gerrit.libreoffice.org/77790 Tested-by: Jenkins Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
2019-05-05Fix remaining uses of gb_SYMBOLStephan Bergmann1-1/+1
...after eeeec33ada5923f1f534334b22c15d6e2c6f1d35 "merge --enable-selective-debuginfo into --enable-symbols" had removed it Change-Id: I83aed6e21c4b983d8645707daa65bd85ec16ff6b Reviewed-on: https://gerrit.libreoffice.org/71798 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-03-11Add -frtti to HarfBuzz CXXFLAGS instead of paching configure.acKhaled Hosny3-19/+1
Change-Id: Ibc16c4e9c4a305d6fff764fcf3964a63c5322e14 Reviewed-on: https://gerrit.libreoffice.org/68921 Tested-by: Jenkins Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
2019-03-08Don'tbuild HarfBuzz with Core Text support on macOS/iOSKhaled Hosny1-1/+0
HarfBuzz 2.x has native support for AAT fonts which is, according to Chrome developers, sgnificantly faster that HarfBuzz Core Text integration. Change-Id: I4d5e861a1958402a6e3ccb720b10f40828c3db6a Reviewed-on: https://gerrit.libreoffice.org/68919 Tested-by: Jenkins Reviewed-by: Khaled Hosny <khaledhosny@eglug.org>
2019-03-08ofz#13602 -fsanitize=vptr' not allowed with '-fno-rtti'Caolán McNamara2-0/+19
Change-Id: I77beadee964f08f87f2fe7cc0daef5cb91151b72 Reviewed-on: https://gerrit.libreoffice.org/68912 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> Tested-by: Caolán McNamara <caolanm@redhat.com>
2019-03-06Record external/harfbuzz/msvc.patch as sent upstreamStephan Bergmann1-0/+2
Change-Id: I47277272170508e9af7617e9b774bbdca05e9ec3 Reviewed-on: https://gerrit.libreoffice.org/68766 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-03-05Upgrade to latest HarfBuzz 2.3.1Stephan Bergmann6-75/+18
As a side-effect, this gets rid of some Clang -fsanitize=implicit-signed-integer-truncation warnings. The various external/harfbuzz/*.patch no longer applied and appear not to be necessary any more. (But a new external/harfbuzz/msvc.patch became necessary.) <https://dev-www.libreoffice.org/src/harfbuzz-2.3.1.tar.bz2> was downloaded from <https://www.freedesktop.org/software/harfbuzz/release/harfbuzz-2.3.1.tar.bz2>, and HARFBUZZ_SHA256SUM in download.lst matches <https://www.freedesktop.org/ software/harfbuzz/release/harfbuzz-2.3.1.tar.bz2.sha256>. Change-Id: Ic85acd14b4f488b3d88ce1bafc93be271928006e Reviewed-on: https://gerrit.libreoffice.org/68731 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-24Drop unnecessary gb_DEBUG_CFLAGSStephan Bergmann1-1/+0
...which was at maximum set to GCC's -finline-limit=0 -fno-inline (solenv/gbuild/platform/com_GCC_defs.mk). Those options were set for debug builds "since forever", but that looks very much like cargo cult: -fno-inline "is the default when not optimizing" anyway (<https://gcc.gnu.org/onlinedocs/gcc-7.4.0/gcc/Optimize-Options.html>), and it is unclear to me how -finline-limit=0 should have any impact beyond -fno-inline (and maybe was present for ancient compilers that only supported -finline-limit but not -fno-inline?). Change-Id: Id6752d03b1b7ec8763defabc5720d4dd08790874 Reviewed-on: https://gerrit.libreoffice.org/66836 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-01-23Drop use of obsolete GCC -fno-default-inlineStephan Bergmann1-1/+1
...that is documented as: "Does nothing. Preserved for backward compatibility." ever since <https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=160384> from 2010. -fno-default-inline was the only value ever set in gb_DEBUG_CXXFLAGS, so the latter can be removed now. The use of gb_DEBUG_CXXFLAGS had accidentally already been removed from gb_LinkTarget__get_debugcxxflags with e751e24250fda31dde52b3c65ca79f86142dc789 "--enable-optimized should be orthogonal to --enable-debug/--enable-dbgutil", and that leaves gb_LinkTarget__get_debugcflags and gb_LinkTarget__get_debugcxxflags with identical definitions, so replace those two with a single gb_LinkTarget__get_debugflags. Some external modules had used only gb_DEBUG_CXXFLAGS, when this was apparently meant to be used in addition to gb_DEBUG_CFLAGS, so those uses have been changed to gb_DEBUG_CFLAGS now. Change-Id: I84ea0ab1233569b0b02ca057240a71f138352381 Reviewed-on: https://gerrit.libreoffice.org/66808 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2018-11-13android: harfbuzz refuses to compile using mmap.Michael Meeks1-0/+1
Not ideal not to use mmap on a small device though, but disable for now. Change-Id: Id595cbc87c93679c1ce186f91ad36a961aee4132 Reviewed-on: https://gerrit.libreoffice.org/63342 Tested-by: Jenkins Reviewed-by: Michael Meeks <michael.meeks@collabora.com>
generated by cgit v1.2.3 (git 2.39.1) at 2025-04-30 21:09:15 +0000