since 689334c8b9.
the new stuff in case is not defined in 0.5.x, but since it's
fallthrough and break anyway one can probably #if(def) it out completely...
version detection using pkg-config. hopefully all distros have it
(didn't check.)
Change-Id: I1c97b0492c00dbd0ee631f98b207ee6e64744c9d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211635
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
On pc Debian testing x86-64 with master sources + clang 21.1,
autogen.sh generates config_host.mk with:
export CC=/usr/bin/ccache clang -std=gnu23
export CC_FOR_BUILD=/usr/bin/ccache clang -std=gnu23
it's because a recent change in autoconf.
The pb is it makes Firebird part building in LO fail.
Add ac_cv_prog_cc_c23=no as a workaround for the moment.
Change-Id: I13f49153e82b4f670fe170ef5df6f072b0c7d336
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/211193
Tested-by: Jenkins
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/rene/LibreOffice/git/master/workdir/CxxObject/vcl/source/filter/jxl/reader.o: in function `readJxl(SvStream&, Graphic&)':
/usr/include/jxl/resizable_parallel_runner_cxx.h:60:(.text+0x3f): undefined reference to `JxlResizableParallelRunnerCreate'
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/rene/LibreOffice/git/master/workdir/CxxObject/vcl/source/filter/jxl/reader.o: in function `JxlResizableParallelRunnerDestroyStruct::operator()(void*)':
/usr/include/jxl/resizable_parallel_runner_cxx.h:34:(.text+0x87): undefined reference to `JxlResizableParallelRunnerDestroy'
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/rene/LibreOffice/git/master/workdir/CxxObject/vcl/source/filter/jxl/reader.o: in function `readJxl(SvStream&, Graphic&)':
././vcl/source/filter/jxl/reader.cxx:56:(.text+0xe3): undefined reference to `JxlResizableParallelRunner'
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/rene/LibreOffice/git/master/workdir/CxxObject/vcl/source/filter/jxl/reader.o: in function `JxlResizableParallelRunnerDestroyStruct::operator()(void*)':
/usr/include/jxl/resizable_parallel_runner_cxx.h:34:(.text+0x199): undefined reference to `JxlResizableParallelRunnerDestroy'
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/rene/LibreOffice/git/master/workdir/CxxObject/vcl/source/filter/jxl/reader.o: in function `readJxl(SvStream&, Graphic&)':
././vcl/source/filter/jxl/reader.cxx:135:(.text+0x47f): undefined reference to `JxlResizableParallelRunnerSuggestThreads'
/usr/bin/x86_64-linux-gnu-ld.bfd: ././vcl/source/filter/jxl/reader.cxx:134:(.text+0x489): undefined reference to `JxlResizableParallelRunnerSetThreads'
/usr/bin/x86_64-linux-gnu-ld.bfd: /home/rene/LibreOffice/git/master/workdir/CxxObject/vcl/source/filter/jxl/reader.o: in function `JxlResizableParallelRunnerDestroyStruct::operator()(void*)':
/usr/include/jxl/resizable_parallel_runner_cxx.h:34:(.text+0x604): undefined reference to `JxlResizableParallelRunnerDestroy'
/usr/bin/x86_64-linux-gnu-ld.bfd: /usr/include/jxl/resizable_parallel_runner_cxx.h:34:(.text.unlikely+0x68): undefined reference to `JxlResizableParallelRunnerDestroy'
$ grep JxlResizableParallelRunner /usr/lib/x86_64-linux-gnu/*so*
[...]
grep: /usr/lib/x86_64-linux-gnu/libQt6WaylandEglCompositorHwIntegration.so: No such file or directory
grep: /usr/lib/x86_64-linux-gnu/libjxl_threads.so.0.11: binary file matches
grep: /usr/lib/x86_64-linux-gnu/libjxl_threads.so.0.11.2: binary file matches
[...]
so we need libjxl_threads, too
Change-Id: I43ed34093d583f72eb2b8710bcb2ddea8ef17e2d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/210116
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
HarfBuzz is a critical LibreOffice dependency and we require many
features of more recent HarfBuzz versions. We are putting our users at
disadvantage by allowing for old HarfBuzz versions.
Distributions that want latest LibreOffice but not latest HarfBuzz can
always use the internal HarfBuzz version.
14.3.0 also provide a few new APIs that were added specifically for
LibreOffice and I’m going to start using them in next commit.
Change-Id: I7c11be3c1bf21d5164f4d34d39361dee88b86d8d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208907
Tested-by: Jenkins
Reviewed-by: Khaled Hosny <khaled@libreoffice.org>
Debian patches firebird to resolve its plugins, intl and conf
directories under the FIREBIRD variable (instead of where it was built)
and we want point that variable at a private directory. But then the
modules aren't loaded and no database opens.
So write a replacement plugins.conf that lists the absolute path of each
plugin module (and the intl conf files) with their macros expanded.
each lib<Name>.so (otherwise found by default) with no entry names gets
an entry of its own.
Change-Id: I2696d7197394b7fe9b7739732deadd2cb2e01acc
Signed-off-by: Caolán McNamara <caolan.mcnamara@collabora.com>
Reviewed-on: https://gerrit.collaboraoffice.com/c/core/+/7989
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Michael Stahl <michael.stahl@collabora.com>
(cherry picked from commit b8407b18adf3c6d552d54d7b6657539e2769afd6)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208882
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
/DEBUG:FASTLINK was available from VS 2017 through VS 2022 and is gone in the
VS 2026 toolset:
https://learn.microsoft.com/en-us/cpp/build/reference/debug-generate-debug-info?view=msvc-180
Its link.exe (14.51) answers the flag with "LNK4315: /DEBUG:FASTLINK is no
longer supported. Using /DEBUG:FULL instead." and links on, so a dbgutil build
would get that warning once per linked target - exactly what
b14cffdc89f9f38e05f346a9051d3420ee3b45cf ("Only use -debug:fastlink with
linkers that support it", 2026-07-17 11:51:25 +0500) set out to avoid for
lld-link.
That probe short-circuited to "supported" whenever the MSVC linker was
selected, so it never got to see this. Run it against the linker that will
actually be used in all cases (link.exe next to cl.exe, when lld-link is not
selected).
While at it, treat any mention of the flag in the probe output as "unusable",
instead of matching the -debug:full fallback wording alone. A linker that
takes the flag says nothing about it, so any complaint, however phrased, is
reason enough not to pass it.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I125a3000ab82aa4b9371069cf4f5fd814a11f599
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7818
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
(cherry picked from commit 3af47b423bbd0bb1882547e394b0b4c37e92de44)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208662
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
fastlink speeds up debug-build links, and MSVC link.exe supports it, but
lld-link does not: it prints "/debug:fastlink unsupported; using /debug:full"
on every link and falls back anyway, cluttering the build output with a
warning per linked target.
Add a configure probe (HAVE_LINK_DEBUG_FASTLINK) that checks whether the
selected linker actually supports the flag, and only pass -debug:fastlink
when it does. The probe tests the linker rather than hardcoding "lld has no
fastlink", so a future lld-link that gains support starts using it
automatically, with no further build-system change.
Signed-off-by: Mike Kaganski <mike.kaganski@collabora.com>
Change-Id: I9f2638449909d75e6e627ca1d53ac56ff8035cca
Reviewed-on: https://gerrit.collaboraoffice.com/c/online/+/7156
Reviewed-by: Noel Grandin <noel.grandin@collabora.com>
Tested-by: Jenkins CPCI <releng@collaboraoffice.com>
(cherry picked from commit b14cffdc89f9f38e05f346a9051d3420ee3b45cf)
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208660
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
As described in the dev mailing list, LibreOffice build fails at the
configuration stage, starting from VS 2026 version 18.7.0.
LibreOffice build errors with Visual Studio 2026 version 18.7.0
https://lists.freedesktop.org/archives/libreoffice/2026-June/094681.html
The root cause of the issue is that clang-cl.exe is re-located in that
version and configure.ac searches in the old places, and does not find
it. The new patch contains an extra 'x64', or the architecture.
Here, $WIN_BUILD_ARCH is used as the architecture.
Change-Id: Ib3e3f518735df5045241f52a2ce86184e47fc87b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/208447
Reviewed-by: Hossein <hossein@libreoffice.org>
Tested-by: Jenkins
Qt on Mac would typically be build & distributed as frameworks, so let's
look for and handle that. We're only handling external frameworks for
now, and because of that, we need to add an rpath to the Qt VCL plugin
so the system knows how to find the frameworks when running LO.
Change-Id: If4bdafe9899faedb18ae873b01aadf38d4132eae
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207981
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Dan Williams <dcbw@libreoffice.org>
unfortunately ant as deployed on the baseline has a bug and expects
SOURCE_DATE_EPOCH to be in milliseconds, and if set in an environment
variable would also override the ant.tstamp.now property even when
explicitly provided at the commandline, so to avoid bogus timestamps
unset it if it was exported in the environment (default build doesn't
export it, but the user may export it to override or provide a value
e.g. when not building from source.
for ant.tstamp.now to work for setting the tstamp value, ant 1.10.2 or
later is required
Change-Id: I2dd53cb99281f46d58a8db35baf71627ed5422f1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207246
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
for reproducible builds, the timestams of zip members must not depend on
checkout date or file creation dates, the metadata should be clear of
those effects.
Only timestamps are rewritten since we want custom order/storage options
for open document files / our make rules should already have
deterministic order (or that determinism is just one additional $(sort…)
call away)
Change-Id: I49341cf3252d5ef5c092508c789fd188f21dc8df
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207142
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
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>
while the git commands needs to be run in SRCDIR, the AC_DEFINE_UNQUOTED
call needs to be done in BUILDDIR, it immediately adds the defines to a
confdefs.h file in the current working directory, the files listed in
AC_CONFIG_HEADER statements then get the values from there.
Instead of splitting the git command and the AC_DEFINE_UNQUOTED
statement, use the -C switch to git to switch to SRCDIR
Change-Id: Ia2622d9ad1a6069cfff3cc4f4d5bb8834a54a856
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207197
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
in preparation of adding options to use use stable timestamps in created
zip files/templates and similar.
also move the block that sets LIBO_THIS_YEAR to the section where
configure switches to SRCDIR to make it work in builddir != srcdir case
Change-Id: I286d7765277cde9d8449de375f522df7c33a6222
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/207015
Tested-by: Jenkins
Reviewed-by: René Engelhard <rene@debian.org>
Updates the configure script to explicitly require the same version of
Python as mentioned as the baseline in the README. This is for both the
version required for building and the version for pyuno.
All versions less than 3.9 are already end-of-life and version 3.11 is
currently in security-fix-only mode so it is probably quite reasonable
to require that.
Previously the configure script only checked for version 3.3, or 3.7 if
internal Harfbuzz is being used. In practice it probably hasn’t worked
to build with anything less than 3.6 since desktop-translate.py started
using f-strings in 2022.
Change-Id: Ice26324f4e7805bc37a0dd07d984451460529249
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/206368
Tested-by: Jenkins
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Reviewed-by: Neil Roberts <nroberts@libreoffice.org>
especiall when creating installsets with high parallelism, the packaging
stage can hang until faked-tcp is killed.
So avoid this race-condition altogether by switching to the sysv backend
if available.
Change-Id: If554abb8fb51218e6055e70c98622be77ecce58e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205896
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
since b8e6595d47 the UCRTSDKDIR was
converted to the native (windows-style) path in the test block already
while previously it was converted as part of the post-AC_CONFIG_FILES
script that mass-converts paths when creating config_host.mk
With the conversion to unix path in wsl < 2.4.5 dropping the trailing
slash from the path, configure then fails with "Could not figure out
what C++ library this is" since it just appends the include path
assuming the trailing slash to be present, resulting in
-IC:/PROGRA~2/WI3CF2~1/10Include/10.0.26100.0/ucrt
^ missing path delimiter here
ultimately failing to include necessary headers and thus failing the
check.
So explicitly check whether the unix-path (that preserves the slash) has
a trailing slash and if so make sure it is also added to the native path
if necessary.
Change-Id: I0ff4e2007af48fc09db4b8a80413dc87f849537a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/205440
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
commit b14583ba37 initially added the
parquet filter with saying
Note that this change makes it possible to load Apache Parquet files
if and only if orcus has been built with the parquet import filter
enabled. Using orcus without the parquet import filter enabled will
not break the build or run-time behavior; you just can't load parquet
files.
This is bad since silently failing like this doesn't tell people what
the problem is. Not having the option at all is clearer and more deterministic.
And the internal liborcus in a "standard" LibreOffice build didn't build with parquet
enabled at all anyway, thus leaving LibreOffice offering the option without even able to
load the files.
This patch adds
a) an explicit --with-parquet-filter configure flag on which the config
is built or not
b) based on that flag also gives --with-parquet-filter to liborcus'
configure. (which then of course will make that liborcus linked
against libparquet. But if people explicitely specify it..)
c) fixes the build of liborcus against arrow 23 (see
https://gitlab.com/orcus/orcus/-/commit/bae0e6e659cf4df2590288f566004eef7096dee4 -
that incidentially also fixed the liborcus build against 22 for me
This is a generalized version of a local patch I carry in Debian - which
I added some time after I made liborcus in Debian *do*
--with-parquet-filter :)
Change-Id: I72b15893fe4fa8e08a556f27b2d6ab942c9858cc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204685
Tested-by: Jenkins
Reviewed-by: René Engelhard <rene@debian.org>
Add android.patch to fix
In file included from /home/tdf/jenkins/workspace/android_arm/workdir/UnpackedTarball/box2d/src/allocate.c:6:
/home/tdf/jenkins/workspace/android_arm/workdir/UnpackedTarball/box2d/src/core.h:50:3: error: Unsupported CPU
50 | #error Unsupported CPU
| ^
/home/tdf/jenkins/workspace/android_arm/workdir/UnpackedTarball/box2d/src/allocate.c:71:14: error: call to undeclared library function 'aligned_alloc' with type 'void *(unsigned int, unsigned int)'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
71 | void* ptr = aligned_alloc( B2_ALIGNMENT, size32 );
|
Downloaded from https://github.com/erincatto/box2d/archive/refs/tags/v3.0.0.tar.gz
Change-Id: I8fa42a5e0317cf0cd7a62bbe9bcfe71c1405184d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/183724
Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org>
Tested-by: Jenkins
commit 08f3f447fb
Date: Wed Apr 22 12:43:32 2026 +0200
remove additional PathFormatUnix wrapper
adjusted the PathFormat function to set
$formatted_path_unix to Unix-style/Cygwin paths
when building in Cygwin.
However, for UCRTSDKDIR, a Windows/mixed style
path is needed.
Use $formatted_path instead of $formatted_path_unix
for these, but keep using $formatted_path_unix for
the directory/file checks in the configure script
itself.
This fixes errors like these for the Cygwin build:
twain32shim.o : error LNK2019: unresolved external symbol __imp___invoke_watson referenced in function "void * __cdecl std::_Allocate_manually_vector_aligned<struct std::_Default_allocate_traits>(unsigned int)" (??$_Allocate_manually_vector_aligned@U_Default_allocate_traits@std@@@std@@YAPAXI@Z)
twain32shim.o : error LNK2019: unresolved external symbol __imp__wcscmp referenced in function "private: static bool __cdecl `anonymous namespace'::ImpTwain::IsTwainClassWnd(struct HWND__ *)" (?IsTwainClassWnd@ImpTwain@?A0xf9c99f7d@@CA_NPAUHWND__@@@Z)
twain32shim.o : error LNK2019: unresolved external symbol __imp__wcslen referenced in function "wchar_t * __cdecl std::_Maklocwcs(wchar_t const *)" (?_Maklocwcs@std@@YAPA_WPB_W@Z)
twain32shim.o : error LNK2019: unresolved external symbol __imp__wcstoul referenced in function _wWinMain@16
twain32shim.o : error LNK2019: unresolved external symbol __imp___calloc_dbg referenced in function "wchar_t * __cdecl std::_Maklocwcs(wchar_t const *)" (?_Maklocwcs@std@@YAPA_WPB_W@Z)
twain32shim.o : error LNK2019: unresolved external symbol __imp___CrtDbgReport referenced in function "void * __cdecl std::_Allocate_manually_vector_aligned<struct std::_Default_allocate_traits>(unsigned int)" (??$_Allocate_manually_vector_aligned@U_Default_allocate_traits@std@@@std@@YAPAXI@Z)
twain32shim.o : error LNK2019: unresolved external symbol __imp__round referenced in function "private: void __thiscall `anonymous namespace'::ImpTwain::ImplXfer(void)" (?ImplXfer@ImpTwain@?A0xf9c99f7d@@AAEXXZ)
twain32shim.o : error LNK2019: unresolved external symbol __imp____acrt_iob_func referenced in function _printf
twain32shim.o : error LNK2019: unresolved external symbol __imp____stdio_common_vfprintf referenced in function __vfprintf_l
twain32shim.o : error LNK2019: unresolved external symbol __imp___wassert referenced in function "double __cdecl o3tl::detail::MulDiv<double>(double,__int64,__int64)" (??$MulDiv@N@detail@o3tl@@YANN_J0@Z)
MSVCRTD.lib(new_scalar.obj) : error LNK2019: unresolved external symbol __callnewh referenced in function "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)
MSVCRTD.lib(new_scalar.obj) : error LNK2019: unresolved external symbol _malloc referenced in function "void * __cdecl operator new(unsigned int)" (??2@YAPAXI@Z)
MSVCRTD.lib(delete_scalar.obj) : error LNK2019: unresolved external symbol __free_dbg referenced in function "void __cdecl operator delete(void *)" (??3@YAXPAX@Z)
MSVCRTD.lib(ftol3.obj) : error LNK2001: unresolved external symbol __except1
Change-Id: I3cd9a551c746d2ab670972473c232997ef81eae8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204767
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
commit 08f3f447fb
Date: Wed Apr 22 12:43:32 2026 +0200
remove additional PathFormatUnix wrapper
adjusted the PathFormat function to set
$formatted_path_unix to Unix-style/Cygwin paths
when building in Cygwin.
However, for JAVA_HOME (used e.g. for the Java
Java include paths and linker flags/paths),
Windows/mixed style paths are needed.
Use $formatted_path instead of $formatted_path_unix
for these.
However, keep using a Unix path for directory
checks, as these wouldn't work with Windows
paths for the WSL-as-helper build.
Once Java 8 is no longer supported, these checks
can be dropped altogether as those directories
don't exist with Java >= 9 any more anyway,
see discussion in [1].
This addresses the following build error seen in
a clean Cygwin build on Windows:
D:/src/lo/master/bean/native/win32/com_sun_star_comp_beans_LocalOfficeWindow.c(29): fatal error C1083: Cannot open include file: 'jawt_md.h': No such file or directory
[1] https://gerrit.libreoffice.org/c/core/+/204766/comments/ff0973b2_f15fdaf3
Change-Id: I11fdd489e49e26a1b99ff9fb822bf8eb3923f399
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204766
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
commit 08f3f447fb
Date: Wed Apr 22 12:43:32 2026 +0200
remove additional PathFormatUnix wrapper
adjusted the PathFormat function to set
$formatted_path_unix to Unix-style/Cygwin paths
when building in Cygwin.
However, for TARFILE_LOCATION, Windows/mixed style
paths are needed.
Use $formatted_path instead of $formatted_path_unix
for these.
Drop the now redundant/obsolete logic using
$formatted_path for the WSL_ONL_AS_HELPER case
further down because with this commit in place, this
is already set accordingly now for both,
Cygwin and WSL.
This fixes the following build error seen
in a clean Cygwin build on Windows:
make[1]: *** No rule to make target '/cygdrive/c/sources/lo-external/boost_1_90_0.tar.xz', needed by 'C:/Users/mwegh/development/git/libreoffice-WORKTREE/workdir/UnpackedTarget/boost_1_90_0.tar.xz'. Stop.
make: *** [Makefile:137: boost] Error 2
Change-Id: Ife951fc0015f6781493bd480a11dfc45e2ad499b
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/204762
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
elioperdreau
Rene Engelhard