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>
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>
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
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>
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>
When not using a system Python, set PYTHON_FOR_BUILD to point to the
python script in the instdir_for_build/program folder. Make sure that
script gets installed by adding it to gb_BUILD_TOOLS_executables and
by adding pyuno to the cross_toolset modules. Make also the
SYSTEM_PYTHON boolean flag visible to the cross-build (in the normal
way, as SYSTEM_PYTHON_FOR_BUILD).
When cross-compiling Python to Linux, pass some ac_cv_* settings that
can't be determined at compile time.
Change-Id: I5224966698dca03df9545f5552671f0dce00b4ca
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/197540
Reviewed-by: Tor Lillqvist <tml@iki.fi>
Tested-by: Jenkins
long obsolete; there's no IBM JDK for 32-bit ppc anymore. And it breaks
creating instdir/program/soffice with +x by cp (sed doesn't keep the
permission, obviously)
Change-Id: I9e8ffc6017056adb5142099a661761c2caaa87c4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/195487
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>
...to enable "the UNO parts (types and servie implementation) of the embindtest
framework (which can also be used independently of the Emscripten build)." And
which e.g. both last year's Lua GSoC project and this year's Rust GSoC project
(<https://gerrit.libreoffice.org/c/core/+/186425> "Add core UNO types for Rust
language binding") enabled locally in their respective dev builds.
Change-Id: I8cf917fbcdaf73e244bd84689a1f29f3aa95f923
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/189363
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
(Which I find useful when working on the C++ code of the Emscripten that is used
to build LO and having ccache's depend mode, CCACHE_DEPEND=1, enabled:
Otherwise, ccache would generally not rebuild our code when included
emscripten/*.h include files have changed.)
Change-Id: Ic513934f81c72232653b5e4c423611571e63ebc6
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/188479
Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tested-by: Jenkins
there was already parts of that in the makefile that would require
running "make gb_GCOV=YES" - but that alone was not enough, you were
also kinda expected to set LDFLAGS on the commandline (or at least it
had bitrotted to this state) - so just make it into a proper configure
switch.
Building with lto fails at least on baseline with
/opt/rh/gcc-toolset-12/root/usr/libexec/gcc/x86_64-redhat-linux/12/ld: /tmp/ccaE1KD4.ltrans31.ltrans.o:(.data.rel.ro.local+0x3befe0)
: undefined reference to `.L1'
/opt/rh/gcc-toolset-12/root/usr/libexec/gcc/x86_64-redhat-linux/12/ld: /tmp/ccaE1KD4.ltrans31.ltrans.o:(.data.rel.ro.local+0x3befe8)
: undefined reference to `.L1'
/opt/rh/gcc-toolset-12/root/usr/libexec/gcc/x86_64-redhat-linux/12/ld: /tmp/ccaE1KD4.ltrans31.ltrans.o:(.data.rel.ro.local+0x3bf018)
: undefined reference to `.L2'
/opt/rh/gcc-toolset-12/root/usr/libexec/gcc/x86_64-redhat-linux/12/ld: /tmp/ccaE1KD4.ltrans31.ltrans.o:(.data.rel.ro.local+0x3bf020)
: undefined reference to `.L2'
[…many more of those with incrementing references…]
So for now warn if both are used.
Change-Id: I2c3427b48174de77a6894293a5e784df8ee24bd1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/186821
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
was needed for the 64bit shell extensions in a 32bit build of
LibreOffice, but that was already broken by
ec0a49ecc7 since that not only removed the
ucrt stuff, but also external/msc-externals/Package_msvc_dlls.mk that
would have registered the files to be packaged into the installation
set. So remove that bit for good and do some related cleanup.
Change-Id: I0b963dcf48eb66cb37d3a6bf017c2ee9aa3fbdf8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/185566
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
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
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>
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>
...otherwise my macOS build with autogen.input containing (among others)
> NINJA=/Users/stephan/lo/lode/opt/bin/ninja
would have failed building ExternalProject_harfbuzz with
> ERROR: Could not detect Ninja v1.8.2 or newer
Change-Id: I39260ae7fea9808fe26b9e63c3c7aaaa4c27103d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/184502
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...for Java versions < 24. As discussed in the comments starting at
<https://gerrit.libreoffice.org/c/core/+/132558/4#message-4fd391160f395455362289909dadb7d2663f4ff2>
"Allow building against JDK 18", the previous
35d9ec3e59 "Remove the
JDK_SECURITYMANAGER_DISALLOWED_FOR_BUILD workaround" had started to resurface
the old "exception and build failure with JDK 21/22/23 on macOS Sequoia."
So keep the workaround for Java versions < 24, and hope that we won't run into
scenarios where we combine a Java version >= 24 (for which the workaround would
cause the new build failure) with an Ant version that requires the workaround.
Change-Id: Ib886f68d5c17ace2384f22672dcc2d0478830228
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182454
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
...that had been introduced with 19de5d97ef "Allow
building against JDK 18" to work around odd failures of ExternalProject_hsqldb
with whatever versions of JDK 18 and Ant I had been using at that time.
However, with java-latest-openjdk-24.0.0.0.36-1.rolling.fc41.x86_64 that
workaround now started to make ExternalProject_hsqldb fail for me with
> ERROR: JVMTI: 112(JVMTI_ERROR_WRONG_PHASE): Cannot get thread info
> ERROR: JVMTI: 112(JVMTI_ERROR_WRONG_PHASE): jvmtiEnv::GetLoadedClasses()
> Error occurred during initialization of VM
> java.lang.Error: A command line option has attempted to allow or enable the Security Manager. Enabling a Security Manager is not supported.
> at java.lang.System.initPhase3(java.base@24/System.java:1947)
apparently because of <https://openjdk.org/projects/jdk/24/>'s
<https://openjdk.org/jeps/486> "JEP 486: Permanently Disable the Security
Manager".
But with the ant-1.10.14-13.fc41.noarch I'm using now, neither
java-21-openjdk-21.0.6.0.7-6.fc41 (I no longer have the problematic-back-then
JDK 18) nor java-latest-openjdk-24.0.0.0.36-1.rolling.fc41.x86_64 appear to need
that workaround anymore anyway (presumably because "an updated version of Apache
Ant [has] become available", as discussed in the commit message of that
19de5d97ef).
Change-Id: Id13b57559df486012c888247c96323716168c97d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/182419
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
it had been deprecated since ndk 13 where it defaulted to clang already
and had been completely removed in ndk 18
nss still checks for it in the nss/coreconf/Linux.mk makefile, but the
paths it tries to set up there are unused/don't exist for a long while.
Change-Id: Ie37104ae59b2143ec4645af3ff437ad06792ee65
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181852
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
My local ASan/UBSan builds of d37c60c5e2b793c0934d431e59c8cb3ff1a170b6
"external/firebird: Drop -fno-rtti from sanitizer builds" against LLVM 21 trunk
had been fine, but <https://ci.libreoffice.org/job/lo_ubsan/3459/> against
lode's LLVM 12.0.1 started to fail with
> ==3374322==ERROR: AddressSanitizer: odr-violation (0x0000007af7a0):
> [1] size=16 'typeinfo for Firebird::Exception' /home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/UnpackedTarball/firebird/src/common/fb_exception.cpp
> [2] size=16 'typeinfo for Firebird::Exception' /home/tdf/lode/jenkins/workspace/lo_ubsan/workdir/UnpackedTarball/firebird/src/common/fb_exception.cpp
> These globals were registered at these points:
> [1]:
> #0 0x440738 in __asan_register_globals.part.0 /home/tdf/lode/packages/llvm-llvmorg-12.0.1.src/compiler-rt/lib/asan/asan_globals.cpp:360:3
> #1 0x68237b in asan.module_ctor (/workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql+0x68237b)
>
> [2]:
> #0 0x440738 in __asan_register_globals.part.0 /home/tdf/lode/packages/llvm-llvmorg-12.0.1.src/compiler-rt/lib/asan/asan_globals.cpp:360:3
> #1 0x7f5ccdec01ab in asan.module_ctor (/workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2+0x9b41ab)
What appears to make a difference there is
<https://github.com/llvm/llvm-project/commit/1ada819c237bf724e6eaa1c82b2742e3eb57a5d5>
"[asan] Default to -fsanitize-address-use-odr-indicator for non-Windows", first
appearing in LLVM 16: My local ASan/UBSan LLVM 21 trunk build, which builds
external/firebird fine, has
> 0000000000ee5166 B __odr_asan_gen__ZTIN8Firebird9ExceptionE
> 000000000045b960 D _ZTIN8Firebird9ExceptionE
in workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql and
> 0000000000e49920 b __odr_asan_gen__ZTIN8Firebird9ExceptionE
> 0000000000b9d100 D _ZTIN8Firebird9ExceptionE
in workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2, but
when I rebuild it with -fno-sanitize-address-use-odr-indicator, it has only
> 000000000045bbc0 D _ZTIN8Firebird9ExceptionE
in workdir/UnpackedTarball/firebird/gen/Debug/firebird/bin/isql and only
> 0000000000b9d1c0 D _ZTIN8Firebird9ExceptionE
in workdir/UnpackedTarball/firebird/gen/Debug/firebird/lib/libfbclient.so.2, and
fails the same way as <https://ci.libreoffice.org/job/lo_ubsan/3459/>.
So make the "Drop -fno-rtti" patch depend on Clang >= 16 (recorded, for
simplicity, with a bespoke new CLANG_16 config_host.mk variable).
Change-Id: I70a8ce8eb535265d592d470718d6b3a6765d5bcd
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/181235
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
There is no point to bundle it, because
1) it is an old version
2) since LibreOffice 7.5 there are built-in number formats in
Calc with the same functionality (using libnumbertext FWIW)
Change-Id: I8cfb24f7e6f045bd51fea620aca6a61269dba77a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180996
Tested-by: Jenkins
Reviewed-by: Andras Timar <andras.timar@collabora.com>
for use in Emscripten --enable-qt6 builds, to e.g. add command line arguments
(like --writer) into qt_soffice.html.
For standard --enable-qt5 Emscripten builds, it works to specify an
> EMSCRIPTEN_EXTRA_SOFFICE_PRE_JS=/path/to/include.js
containing
> Module.arguments = ['--writer'];
to make qt_soffice.html open a Writer document. Due to how the Qt loading has
changed in Qt6, that no longer works for --enable-qt6 Emscripten builds. But
what works there now is to instead specify an
> EMSCRIPTEN_EXTRA_QTLOADER_CONFIG=arguments:['--writer']
(The sed -z option that is necessary to replace text spanning a newline is a
non-standard GNU extension, but lets assume that this is only executed for
cross-builds from Linux that use GNU sed.)
Change-Id: I31372a7a1f8fccbe0fe2594614bf5846e5e5c95f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/180821
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
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>
jom (https://wiki.qt.io/Jom) is a parallel version of nmake that
especially helps with building openssl since everything is compiled
individually/the compiler cannot use parallelism either.
Also in a LibreOffice build there's not much else that can be done in
parallel/other stuff requires openssl to be built to continue.
Change-Id: Ib16b0f947991a1d3255aeae7dc5d9bdee0b157a0
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/177743
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Tested-by: Jenkins
Because some architecture(such as riscv64) does not support NaN
payload (NaN propagation), skipping the related tests might be a
good choice for builders who has already known the risk of lacking
NaN payload support.
Currently the tests that could be skipped via --disable-nan-tests are:
- rtl_math: test_payloadNaN
- sc_ucalc_formula2: testExternalRefFunctions
- sc_ucalc_formula2: testFuncGCD
- sc_ucalc_formula2: testFuncLCM
- sc_ucalc_nanpayload: testNanPayload
Change-Id: Ia8834595a8b469d8c542809b3e580a3f6316ef20
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/174801
Reviewed-by: René Engelhard <rene@debian.org>
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
Reviewed-by: Eike Rathke <erack@redhat.com>
Tested-by: René Engelhard <rene@debian.org>
...which I've seen fundamentally working when building with recent emsdk against
recent Qt6 trunk (and including <https://github.com/qt/qtbase/pull/108> "Update
the check for WebAssembly JSPI support") and running on recent Chrome (with JSPI
enabled under <chrome://flags/>)
Change-Id: I98c11c5ee7e95b135ddc33c95c95752055ecd4c5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/176031
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
...and just unused dummies since 3.1.58, so don't install them for >= 3.1.58,
even if the dummies would still be available for < 3.1.68
Change-Id: Ida55be2fa3b75982bfd764b7b2676e63c092fe79
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/175822
Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
Tested-by: Jenkins
Tomaž Vajngerl