...after 7f1335390e "Build harfbuzz-subset",
> wasm-ld: error: --shared-memory is disallowed by hb-subset-input.cc.o because it was not compiled with 'atomics' or 'bulk-memory' features.
> em++: error: '/home/tdf/lode/emsdk/upstream/bin/wasm-ld @/tmp/emscripten__e1rcozh.rsp.utf-8' failed (returned 1)
> make[1]: *** [/home/tdf/jenkins/workspace/lo_gerrit/tb/src_wasm/desktop/Executable_soffice_bin.mk:10: /home/tdf/lode/jenkins/workspace/lo_gerrit/tb/build_master/instdir/program/soffice.js] Error 1
(<https://ci.libreoffice.org/job/lo_daily_tb_linux_wasm/1338/>). Probably
doesn't hurt to unconditionally add that thread_dep dependency here (which is
also unconditionally used for libharfbuzz, via harfbuzz_deps).
Change-Id: I6dd56a3ce61c855a734db1660d0b3280cbfdaf42
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/199996
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Otherwise you will get linking errors if core is configured with that
option.
Change-Id: Id0982fb7f15f7d185b5fe4eaa15e905464d435f4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197508
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Jenkins
people didn't read configure's warnings and systemwide installed copy of
meson just causes too many conflicts or even if people read the message
they'd still break the idea behind fully-internal python.
If the user specifies MESON in autogen.input it will be called as
specified, if configure autodetects it, it will be prefixed with the
python command used for building.
meson requires python 3.7, so if harfbuzz is enabled configure now also
now checks for that (can by bypassed by setting PYTHON in autogen.input
Change-Id: I6535c9f421fe865b389a87252163ab99d617b7b0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185032
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
--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
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
With the harfbuzz build having been switched to meson
in commit
commit ae24fc8c63
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>
After df83ad933b "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 736998ccef "Only
run meson from python when it apparently needs to be" (that had been removed
with df83ad933b "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>
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 df83ad933b / 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>
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 736998ccef
(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>
...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 ae24fc8c63 "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>
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>
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
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>
This is basically ea68de2968 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>
Caolán McNamara