Not only the freetype headers, but also freetype linker
flags are needed when building using internal cairo.
Adjust accordingly. (The 'freetype' external already
uses the 'freetype_headers' one, so specifying only
'freetype' is enough.)
This fixes the following build error otherwise seen in
a wasm/Emscripten build after
commit ea7166ec8b
Date: Fri Jul 24 18:01:51 2026 +0300
vcl: Don’t link against freetype
It is not used directly anymore.
:
em++: warning: EXPORT_EXCEPTION_HANDLING_HELPERS is deprecated (getExceptionMessage is exported anyway when ASSERTIONS or EXCEPTION_STACK_TRACES is set, which are set by default at -O0. At -O1 or above, you can export it separately by -sEXPORTED_RUNTIME_METHODS=getExceptionMessage,decrementExceptionRefcount.). Please open a bug if you have a continuing need for this setting [-Wdeprecated]
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Outline_Transform
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Outline_Decompose
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Done_Face
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_New_Face
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Set_Transform
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Set_Char_Size
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_MM_Var
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Var_Design_Coordinates
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Done_MM_Var
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_MM_Var
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Var_Design_Coordinates
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Set_Var_Design_Coordinates
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Done_MM_Var
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Init_FreeType
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Paint
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Paint
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Layer
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Layer
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Load_Glyph
wasm-ld: error: /home/michi/development/git/libreoffice-WORKTREE-wasm/workdir/UnpackedTarball/cairo/builddir/src/libcairo-lo.a(cairo-ft-font.c.o): undefined symbol: FT_Get_Color_Glyph_Layer
wasm-ld: error: too many errors emitted, stopping now (use -error-limit=0 to see all errors)
Same also seen in the Tinderbox wasm builds:
https://ci.libreoffice.org/view/tb%20platform%20status/job/lo_daily_tb_linux_wasm/1547/console
Change-Id: Iea8725f9177417cdd3d6e410f693b9ac46d95e78
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211510
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
The Lpsolve solver and the CoinMP solver are both used for the same
thing: a linear model, with optional integer variables by branch
and bound. CoinMP (CLP plus CBC) is the more capable and better
maintained of the two, so the lp_solve one adds a second bundled
dependency and a parallel copy of the solver code for no capability
the other lacks.
Remove the LpsolveSolver component, the bundled lp_solve external
(and its colamd dependency, which only lp_solve used), and all the
build, configure, packaging and license references to them.
A document may still name com.sun.star.comp.Calc.LpsolveSolver as
its engine. SolverSettings now reads that name as the CoinMP
solver, which solves the same model, so such documents keep
working.
The Calc solver test that exercised the engine now uses CoinMP. Its
knapsack model has a single optimal total value of 6987, which fills
the weight capacity of 1000 exactly and which CoinMP finds. The
lp_solve run had returned a suboptimal 6981, so the test now expects
the true optimum.
The build setup changes only take effect after re-running autogen.
Signed-off-by: Tomaž Vajngerl <tomaz.vajngerl@collabora.co.uk>
Change-Id: Ia14d8c491779873da6b0157aa524056275adf8f5
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/3810
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit e77738a7ca7d44fd9d1f852e26d46e3a6d60467b)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208038
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
The problem is that `$(...)` is evaluated by make while parsing, while
the assignments `python_arch_subdir=amd64/` etc are evaluated by `$(eval
...)` in a separate/later phase, so the first time
`gb_LinkTarget__use_python` is used it will be missing the subdirectory.
How this has ever worked is a mystery.
Signed-off-by: Michael Stahl <michael.stahl@collabora.com>
Change-Id: I6a026a37f54eccaf65a4df71b30acd3389373b6b
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/2551
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
(cherry picked from commit daf016a65c5f9d0ff7f9aaa55020c377a484b350)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208014
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
txNew, txFree and doSingleFileSet are public now, so the extern_tx
patches go away.
The mergeFonts crash fix is merged upstream.
The noverbose patch is replaced by a SAL logger installed through
slogger::getLogger.
A new fatal-callback patch lets fatal errors raise exceptions, which
appSpecificFree used to do.
afdko 5.0 replaces makeotfexe with addfeatures, drops the typecomp
Type 1 to CFF converter, and rewrites most of c/shared in C++.
hotconv now only reads CFF, so makeotf() first converts its Type 1 input
to bare CFF with tx, the same step the upstream makeotf driver script
performs.
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Change-Id: I1e5b6ac8413eb66d81034f4f1d0b7f2e46e12233
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/4251
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
(cherry picked from commit 6c40019917bd6e88f6b54d0a2d53d64729c64166)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207285
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Xisco Fauli <xiscofauli@libreoffice.org>
commit 430f603c6a
Author: Tor Lillqvist <tml@collabora.com>
Date: Tue Feb 25 19:52:15 2025 +0200
Make --enable-headless possible also on Windows, for CODA-W
[...]
In the --enable-headless case, freetype, fontconfig and cairo are
built. For now, cairo is built as a Library (DLL), but fontconfig and
freetype as StaticLibrary. Possibly should change these to DLLs,
too. (See preceding commits.) Do not build the vclplug_win.
had introduced support for --enable-headless on
Windows.
As described in the commit message, using the
--enable-headless autogen switch would result in vclplug_win
(i.e. the VCL plugin that provides the UI on Windows)
automatically getting disabled unconditionally.
As described in tdf#170932, this e.g. prevents using
headless mode for document conversion while still
allowing to start LO with a UI with the same build.
Separate the two features:
No longer disable vclplug_win automatically anymore when
--enable-headless is used.
Instead, introduce a new separate --disable-win
autogen switch to explicitly disable the win vcl plugin
(similar to other existing autogen params like
--disable-gtk3 to disable the gtk3 VCL plugin on Linux).
Add that new --disable-win switch to the
CODAWindows distro config, to achieve the original
goal of both enabling headless and disabling vclplug_win
for that build configuration.
Change-Id: I54bc34981327244aa1c8b0aa5b6277ffd1fb4531
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/202043
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@iki.fi>
it fails to build without WINBUILD_ACKNOWLEDGE_DEPRECATED with
WARNING:
The winbuild build system is deprecated and will be removed in
September 2025 in favor of the CMake build system.
curl dropped winbuild support in 8.17.
See https://curl.se/ch/8.17.0.html
Change-Id: I236414c670d1d62d82c5a430e2abdbf71a50a2ff
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/201470
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
We variously look at both ENABLE_HEADLESS and USE_HEADLESS_CODE to
check for the --enable-headless case. Are both really needed?
In the --enable-headless case, freetype, fontconfig and cairo are
built. For now, cairo is built as a Library (DLL), but fontconfig and
freetype as StaticLibrary. Possibly should change these to DLLs,
too. (See preceding commits.) Do not build the vclplug_win.
Windows-specific fixes to the headless vcl code, and headless-specific
fixes to some Win32 vcl code. Use <tools/UnixWrappers.h> where
appropriate instead of <unistd.h>, <sys/mman.h>, etc.
fontconfig already has code for Windows, but likely things will break
on machines with a non-ASCII name for the Windows fonts directory, or
for funky font names. Should eventually make it use the new
<tools/UnixWrappers.h>.
Change-Id: Id3a1313083b1c7c44b0b26819c1ffb5138e15bc4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194573
Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/196980
Tested-by: Tor Lillqvist <tml@iki.fi>
Reviewed-by: Tor Lillqvist <tml@iki.fi>
and use the same config.h in all platforms.
Compiling these libraries only takes a few seconds
so no need to exclude Windows here
it should also fix the win arm64 build
This patch reverts
commit e4421ce01d
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Mon Nov 10 22:35:22 2025 +0100
sqlite3: don't create a static library on Windows
and part of
commit 1cb84d60d9
Author: Xisco Fauli <xiscofauli@libreoffice.org>
Date: Thu Oct 30 20:11:23 2025 +0100
external: add lzma
Change-Id: Ia66242d4fef78cf8d99f853db4c9eee2e24c62ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/194023
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
...after 2b515d095d "upgrade pixman and cairo".
For one, building ExternalProject_cairo failed with
> Run-time dependency fontconfig found: NO (tried pkgconfig and cmake)
> Not looking for a fallback subproject for the dependency fontconfig because:
> Use of fallback dependencies is disabled.
>
> meson.build:271:17: ERROR: Dependency 'fontconfig' is required but not found.
and
> Called: `/usr/bin/pkg-config --cflags fontconfig` -> 1
> stderr:
> Package libxml-2.0 was not found in the pkg-config search path.
> Perhaps you should add the directory containing `libxml-2.0.pc'
> to the PKG_CONFIG_PATH environment variable
> Package 'libxml-2.0', required by 'fontconfig', not found
in workdir/UnpackedTarball/cairo/builddir/meson-logs/meson-log.txt, because
workdir/UnpackedTarball/fontconfig/fontconfig.pc contains
> Requires.private: libxml-2.0 >= 2.6
so add workdir/UnpackedTarball/libxml2/libxml-2.0.pc to PKG_CONFIG_PATH (TODO:
even though its contents point to /usr/local? but that seems good enough to get
the build going).
For another,
> [LNK] Executable/soffice.js: wait for lock at Mon Sep 29 10:23:58 AM UTC 2025
> [LNK] Executable/soffice.js: got link lock at Mon Sep 29 10:24:03 AM UTC 2025
> em++: error: /home/sberg/lo-wasm-upstream/core/workdir/UnpackedTarball/pixman/pixman/.libs/libpixman-1.a: No such file or directory ("/home/sberg/lo-wasm-upstream/core/workdir/UnpackedTarball/pixman/pixman/.libs/libpixman-1.a" was expected to be an input file, based on the commandline arguments provided)
> make[1]: *** [/home/sberg/lo-wasm-upstream/core/desktop/Executable_soffice_bin.mk:10: /home/sberg/lo-wasm-upstream/core/instdir/program/soffice.js] Error 1
failed to link, so adapt the path in RepositoryExternal.mk.
Change-Id: I925f4fbcaabd58b0de074575293ba9b5366f2cf6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191623
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
fast_float implements C++17 from_chars for floating-point types, which
is still unavailable even in the latest versions of compilers e.g. for
macOS. It is maintained, unlike dtoa; it is said to be adopted as the
from_chars implementation for gcc. It is header-only, which simplifies
many things.
Change-Id: I6b597d4d35a076930e6e35f4f8cff3ca84f48ba1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/191248
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Unfortunately it has 144 dependencies so hack Makefile.fetch to invoke
cargo fetch to get them all at once, based on the Cargo.lock file
extracted from the tarball; this all ends up in a "cargo" subdirectory
below $TARFILE_LOCATION.
Then $CARGO_HOME must be set consistently in the ExternalProject file
and cargo invoked with --offline to prevent downloading during the
build; altogether uses about 720 MB of storage here.
Change-Id: I6126fdd988f12bf9da48b6c2d9123d349eb7cb96
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186903
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
those were from a time where there was 64bit Windows, but no 64bit
builds of LibreOffice/OpenOffice.org - now the only usecase for 32bit
LibreOffice is to use it on 32bit-only machines…
Change-Id: Icf1eacafd9e157788e8ec5a035716327492f5c2c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185565
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Add a config header for this, and split yrs.hxx in two because the
actual libyrs.h is only needed in 2 files.
Change-Id: I30453fda3082f977e328ed56a4a101743ecdd586
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185329
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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
Compile for Windows with LO infrastructure (not the only external lib
where we do this).
Remove unneeded include of <err.h> in libeot.c that isn't used, but
Windows doesn't have <err.h> - it's a BSD / Linux thing.
Only compile libeot.la and not the eot2ttf binary (which uses err.h so
it doesn't compile on Windows).
Change-Id: I26afb2b7bcf0bdf0d2ce0bdbcfceb10599d599e1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185057
Tested-by: Jenkins
Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
This can be enabled in configure via --with-yrs=...; see also README.yrs
Currently this is hardcoded to run over a local named pipe.
Everything related to editengine is implemented in EditDoc and made
accessible via its wrapper classes; everything related to communication
and accessing sw's comment is implemented in sw::DocumentStateManager.
The acceptor starts in SwView::SwView(), once SwPostItMgr exists.
There is a hack in SfxFrameLoader_Impl::load() to fetch the document
that the accepting soffice has loaded, and load it in the connecting
soffice as well.
Change-Id: I89476b5864b70f479bcf15989374c1c65b5da9ea
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175652
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Integrate build system support for the Zstandard (zstd) library and
implement the corresponding C++ decompression stream classes, enabling
future use of zstd-compressed streams in ZIP packages.
Build System (Part 2a):
- Add `--with-system-zstd=[yes|no|auto]` configure option.
- Implement system library checks (`zstd.h`, `libzstd`) in configure.ac.
- Define rules (`external/zstd/*`) for downloading and building the
internal zstd static library (decompression components only).
- Set up necessary CFLAGS/LIBS via configure.ac and config_host.mk.in.
- Configure linking via RepositoryExternal.mk (`gb_LinkTarget__use_zstd`).
- Update auxiliary files (download.lst, distro-configs, etc.).
C++ Implementation (Part 2b):
- Implement `InflateZstd` (in `include/package`) and `InflaterBytesZstd`
(in `package/inc`) inheriting from `Inflater`/`InflaterBytes`.
- Use the zstd streaming API (`ZSTD_decompressStream`) following the
existing single-call pattern established by the zlib implementation.
- Manage context (`ZSTD_DCtx`) and input buffer (`ZSTD_inBuffer`) state.
- Handle errors, stream completion (`ret == 0`), and input truncation.
- Add new classes to `package/Library_package2.mk` build.
This completes the infrastructure for zstd decompression support.
The next step (Part 2c) involves adding logic to select the
appropriate Inflater based on the ZIP entry's compression method ID.
Change-Id: Ia673f3f19b6a751ba5225394fcf8c3f145c4ae63
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184243
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
$(call gb_ExternalExecutable_get_dependencies,python) was incomplete
since at least "import _ctypes" as done by meson requires libffi to be
available in instdir. So depend on the package instead of the project.
Change-Id: I8665aeda74cca994e2ba8591278b4b5c8d9ff2b5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183851
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
There is no simple "Windows is 10 or newer" check in MSI, with the
Microsoft policy of "you don't need to know real Windows version".
See also https://developercommunity.visualstudio.com/t/detect-a-windows-version-from-msi/412198
The values that MSI sees (e.g. on my Win11) are:
Property(C): VersionNT = 603
Property(C): VersionNT64 = 603
Property(C): WindowsBuild = 9600
So those can't be used for the check. I use the WINMAJORVER that is
read from registry (Software\Microsoft\Windows NT\CurrentVersion).
There is no more need to check and install UCRT; it was dropped.
Change-Id: Ic02d6aeb965e9684bafd4357f969980f77000e73
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/178049
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
there was a system Java-WebSocket in Fedora 35, f.e. but unaware
if this is actively packaged standalone in contemporary distros,
but useful for the coverity build case.
Change-Id: Id6393dbfb1c449b75391752a8bb5e5ea4481a084
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/173725
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Michael Weghorn