Age | Commit message (Collapse) | Author |
|
At least building on Fedora 37 with dconf-devel-0.40.0-7.fc37.x86_64 against
recent LLVM 17 trunk libc++ started to fail now with
> In file included from configmgr/source/dconf.cxx:25:
> In file included from /usr/include/dconf/dconf.h:23:
> In file included from /usr/include/dconf/common/dconf-enums.h:23:
> In file included from /usr/include/glib-2.0/glib.h:34:
> In file included from /usr/include/glib-2.0/glib/gasyncqueue.h:34:
> In file included from /usr/include/glib-2.0/glib/gthread.h:34:
> In file included from /usr/include/glib-2.0/glib/gatomic.h:30:
> In file included from /usr/include/glib-2.0/glib/glib-typeof.h:44:
> In file included from ~/llvm/inst/bin/../include/c++/v1/type_traits:430:
> ~/llvm/inst/bin/../include/c++/v1/__type_traits/aligned_union.h:23:1: error: templates must have C++ linkage
> template <size_t _I0, size_t ..._In>
> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> configmgr/source/dconf.cxx:19:1: note: extern "C" language linkage specification begins here
> extern "C" {
> ^
because the missing extern "C" has meanwhile been added to upstream dconf with
<https://gitlab.gnome.org/GNOME/dconf/-/commit/f860ddcc6a501b982d82c5630c73936bd611ad8a>
"common: Add missing G_BEGIN/END_DECLS" towards tag 0.40.0.
So the easiest fix here appears to be to bump our requirements to that dconf
version 0.40.0: The one case I'm aware of that explicitly wants dconf support
is downstream Fedora and RHEL builds, which already have dconf 0.40.0
(cf. most recent
<https://src.fedoraproject.org/rpms/dconf/blob/a9987b0abe15133d091bcd390fd33077881567ae/f/dconf.spec#_4>
for f37 and most recent
<https://gitlab.com/redhat/centos-stream/rpms/dconf/-/blob/1bb6b46da242b75e5e1864f5c97ab6e592ca60ba/dconf.spec#L4>
for e9s). On the other hand, the TDF Linux release builds are done with an
explicit --disable-dconf in distro-configs/LibreOfficeLinux.conf (since
ecc617e797aa5ed329668114e54ec7ffa5c0e87b "configmgr: support reading from a
dconf layer (WIP)") and the Flatpak builds on Flathub are done against an
org.freedesktop.Sdk//22.08 where no dconf support is detected at all (for the
most recent LO 7.5.1 build on Flathub see
> checking for DCONF... no
> checking whether to enable dconf... no
at <https://buildbot.flathub.org/#/builders/5/builds/3184/steps/8/logs/stdio>
for aarch64 and at
<https://buildbot.flathub.org/#/builders/5/builds/3184/steps/8/logs/stdio> for
x86_64).
Change-Id: I559d2ac8712dbe2b40c9b881314b88d1cc8eaf43
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148887
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
→ add back OPENSSL as a permissable sub-build target and explicitly
enable openssl when cross-compiling for windows_aarch64
partially reverts 4132bd5477c25a505f7bfbee1e7dcf6602c927d3
Change-Id: Ic162a2f0c6db377eadedb149fb428f0f015539f9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148688
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
As explained in the /Zc:preprocessor documentation [1], it enables "a token-based
preprocessor that conforms to C99 and C++11 and later standards", available since
Visual Studio 2019 version 16.5.
It helps to workaround an IntelliSense bug [2], which disables highlighting and
code completion in the IDE integration when certain Boost libraries are included;
but using a better preprocessor can't hurt in general, right?
[1] https://learn.microsoft.com/en-us/cpp/build/reference/zc-preprocessor
[2] https://developercommunity.visualstudio.com/t/IntelliSense-reports-many-errors-for-the/10287480#T-ND10303205
Change-Id: I5268f2dd4acf01cc1da23cfe76653c2f6c688c05
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148484
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
Change-Id: I9f97c3990064db88fccf9269deb62414bfb6c3b8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/148011
Tested-by: Rizal Muttaqin <rizmut@libreoffice.org>
Reviewed-by: Rizal Muttaqin <rizmut@libreoffice.org>
|
|
Change-Id: I90b2765bdad5fe753288420b01a5395bcf22f44f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147885
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Just using "-L... -l..." will cause dynamic linking if a matching system
library is found.
Change-Id: I9bc3ee1fb1351336f73c3c9219526749dffe546e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146907
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.com>
|
|
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>
|
|
NDK 24 dropped support for API versions < 19,
quoting [1]:
> * Jelly Bean (APIs 16, 17, and 18) is no longer supported. The minimum OS
> supported by the NDK is KitKat (API level 19).
Therefore, use API level 19 for these (and unknown) NDKs unless
anything greater has explicitly been specified using the
`--with-android-api-level=<VERSION>` autogen switch
(or is default for the architecture, s. above).
Update the Jenkins config to use NDK 25 for the Android
builds as discussed in the ESC meeting on 2023-01-26 [2].
[1] https://developer.android.com/ndk/downloads/revision_history
[2] https://lists.freedesktop.org/archives/libreoffice/2023-January/089878.html
Change-Id: Ib8e65f433ee89ff1bc12432722570bf8f9f7ed85
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146135
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
No logical change intended. This is in preparation of
using `ANDROID_API_LEVEL` in the NDK check in a follow-up commit.
Change-Id: I746cae640a57a49efbdefd8ba00dcc1c4edc4ef9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146134
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
While e.g. NDK 23.0.7599858 has both,
`$HOME/Android/Sdk/ndk/23.0.7599858/sources/cxx-stl/llvm-libc++/libs/x86/libc++_shared.so`
and
`$HOME/Android/Sdk/ndk/23.0.7599858/toolchains/llvm/prebuilt/linux-x86_64/sysroot/usr/lib/i686-linux-android/libc++_shared.so`
(with the same content), NDK 25.1.8937393 no longer
ships that under the former path scheme, just the latter.
Therefore, use that one when copying the library,
in preparation to add support for NDK 24 and 25.
Change-Id: I20894701f4f436f41781467b57ec4f5311a8317f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146133
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
When an Android API level is explicitly set with the
`--with-android-api-level` switch introduced in
commit 4c0bccbb21ba022fd9d630eb1d9ae34673b4dc11
Date: Thu Jul 4 09:06:49 2019 +0200
android: Allow specification of the API level.
, use that for the minSdkVersion for the Android Viewer app
and the API level for the NSS build, rather than leaving
that hard-coded at API level 16.
Building with a newer API level means that the
app won't run on devices with older API levels.
With this in place, this will be recognized at
install time (installation will fail: INSTALL_FAILED_OLDER_SDK)
rather than crashing at run time.
Change-Id: Id6047b768d265b965696f3a3161d7828e5f3696e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146127
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Using lld instead of hard-coding ld.gold speeds up
linking liblo-native-code.so from about 40 seconds
to about 10 seconds for my x86 debug Android build with
NDK 23.2.8568313.
lld was added in NDK 21, made default in NDK 22 [1].
lld doesn't know the `--no-keep-files-mapped` option,
so drop that as well.
ld.gold had previously been hard-coded in
commit c6dadf5035c8e1c31dbd3fccec167bd4a906bf54
Date: Fri Nov 1 17:57:17 2019 +0100
android: Fix linking of liblo-native-code.so on aarch64.
, but lld wasn't available yet back then.
To make sure that lld is used by default, NDK >= 22
has to be used.
In addition, due to a clang bug in NDK 22.1.7171670 [2]
("Misspelled -fnostack-clash-protection"), building for
aarch64 Android with that NDK version would fail as follows:
clang++: error: unknown argument '-fno-stack-clash-protection'; did you mean '-fnostack-clash-protection'?
clang++ version:
$ /home/michael.weghorn/Android/Sdk/ndk/22.1.7171670//toolchains/llvm/prebuilt/linux-x86_64/bin/clang++ --version
Android (7155654, based on r399163b1) clang version 11.0.5 (https://android.googlesource.com/toolchain/llvm-project 87f1315dfbea7c137aa2e6d362dbb457e388158d)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/michael.weghorn/Android/Sdk/ndk/22.1.7171670//toolchains/llvm/prebuilt/linux-x86_64/bin
Rather than work around that bug on LO side, require
NDK 23.x right away, since that provides a clang where this is
fixed.
Both, non-debug as well as `--enable-dbgutil` builds
with NDK version 23.2.8568313 were successfully tested
for all 4 supported architectures and these devices:
* aarch64: Fairphone 3 Plus, LineageOS 19 (Android 12), API 31
* arm32: Samsung Galaxy S4 I9505, LineageOS 17.1 (Android 10), API 29
* x86:
* AVD: Nexus 4, API 16
* AVD: Pixel 2, API 30
* x86_64: AVD: Pixel 2, API 33
[1] https://developer.android.com/ndk/downloads/revision_history
[2] https://bugs.llvm.org/show_bug.cgi?id=47139
Change-Id: I9ea714255faf29d50bb5f8e206f13495637da867
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146119
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
Relevant announcement from revision history for NDK 23 [1]:
> * GNU binutils, excluding the GNU Assembler (GAS), has been removed. GAS
> will be removed in the next release. If you are building with
> -fno-integrated-as, file bugs if anything is preventing you from
> removing that flag.
Therefore, switch from uses of GNU binutils to the
corresponding LLVM tools instead.
NDK 20.x doesn't provide `llvm-ranlib` yet, so bump the minimum
version to 21.x.
Also drop the previous uses of `ANDROID_BINUTILS_PREBUILT_ROOT`,
which appear to no longer be relevant by now.
commit 4082a18406c18af7b4fcef7bd501c3679c3be56b
Date: Wed Nov 22 23:08:06 2017 +0100
android: use unified headers and llvm-c++ STL (x86) with NDK 16
gnustl (and others) are to be removed in future versions of the ndk
also bump gradle and build-tools to current versions along with it
arm unfortunately crashes with llvm-c++, so keep with gnustl for now/fix
that later
that introduced one of those uses mentions issues on ARM, but building
and running the app at least on my 32-bit ARM device (Samsung Galaxy S4 I9505,
LineageOS 17.1/Android 10) didn't show any issues in a quick test
with this change in place.
Update the Jenkins config to switch from the now no longer
supported NDK 20.1.5948944 to 23.2.8568313 for which building and
running the app has been tested on devices for all of the four
supported architectures with upcoming change
Change-Id I9ea714255faf29d50bb5f8e206f13495637da867
"android: Require NDK 23 and use default linker lld" in place
on top, s. that one's commit message for more details.
Note however that the NDK version will be further updated to use
NDK 25 in upcoming change
Change-Id Ib8e65f433ee89ff1bc12432722570bf8f9f7ed85
("android: Support NDK 24.x and 25.x, use NDK 25 for Jenkins").
[1] https://developer.android.com/ndk/downloads/revision_history
[2] https://lists.freedesktop.org/archives/libreoffice/2023-January/089878.html
Change-Id: I7645f8025d42f0fa384b5bceb31bb4b1c0a44cb5
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146118
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
Tested-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This e.g. makes this find the correct moc on Arch Linux,
where the Qt 6 moc is provided under `/usr/lib/qt6/moc`
by package `qt6-base`.
Change-Id: Iefca23e6391a952eb79108260ae1417fc75ad0ef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146781
Tested-by: Jenkins
Reviewed-by: Heiko Tietze <heiko.tietze@documentfoundation.org>
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This way, it is determined at configure time
if the moc meant to be used for Qt 6 is actually a Qt 5
one, as happened e.g. on Arch Linux without
upcoming Change-Id Iefca23e6391a952eb79108260ae1417fc75ad0ef
("qt6 configure: Search for Qt 6 moc in more locations").
Fail at configure rather than build time in such cases.
Change-Id: I2ada2045f41f08bf339920d043226f9b36c335b4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146780
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
This is the minimal version to provide the functionality we currently
check for. Some important LO functionality currently depend on idfdef'd
HarfBuzz code, and some distributions build against old system HarfBuzz
leading to user bug reports that are tricky to track down, e.g:
tdf#153048 and tdf#153470.
Change-Id: I7d58ec46f8fd340d2592887c0088876d71351771
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146674
Tested-by: Jenkins
Reviewed-by: خالد حسني <khaled@aliftype.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
|
|
MS telemetry inside VsDevCmd.bat causes problems for the autogen.sh
script which uses it to find the Visual Studio C/C++ standard library
via the environment variables that show the UCRT path and version.
VsDevCmd.bat is the "Developer Command Prompt for Visual Studio".
The telemtry is disabled by:
set VSCMD_SKIP_SENDTELEMETRY=1
This change resolves the problems described in tdf#153476.
Change-Id: I8b77a2ca0c3577b3ba490723ab7901f463562578
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146677
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
|
|
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_linux_s390 is
apparently dead and should thus be removed. However, that was the only bridge
implementation for 32-bit S390, which implies that support for the 32-bit S390
architecture as a whole is dead and should thus be removed.
Change-Id: I18b3b4fa11df4ce693107bad6bbea2fab1c19f26
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146058
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
As discussed in the mailing list thread starting at
<https://lists.freedesktop.org/archives/libreoffice/2023-January/089808.html>
"Plan to remove dead C++ UNO bridge implementations (bridges/source/cpp_uno/*)",
the bridge implementation at bridges/source/cpp_uno/gcc3_aix_powerpc is
apparently dead and should thus be removed. However, that was the only bridge
implementation for AIX, which implies that support for the AIX platform as a
whole is dead and should thus be removed.
Change-Id: I96de3f7f97d4fd770ff78256f0ea435383688be9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146057
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: Ia0d15eb3e235fbd750b818009b5168c61c6ff0ec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139549
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
Tested-by: Jenkins
|
|
Change-Id: I288b5b54bd07d951bcc68afda7514bde730193dc
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146107
Tested-by: Jenkins
Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
|
|
At least for these 2 configurations, building the app with
NDK 22.1.7171670 worked fine:
x86 dbgutil build:
--build=x86_64-unknown-linux-gnu
--with-android-ndk=/home/michi/Android/Sdk/ndk/22.1.7171670/
--with-android-sdk=/home/michi/Android/Sdk
--with-distro=LibreOfficeAndroidX86
--enable-sal-log
--with-external-tar=/home/michi/development/libreoffice-external
--enable-ccache
--enable-dbgutil
--with-jdk-home=/usr/lib/jvm/java-17-openjdk-amd64/
32-bit ARM release build:
--build=x86_64-unknown-linux-gnu
--with-android-ndk=/home/michi/Android/Sdk/ndk/22.1.7171670/
--with-android-sdk=/home/michi/Android/Sdk
--with-distro=LibreOfficeAndroid
--with-external-tar=/home/michi/development/libreoffice-external
--enable-ccache
--with-jdk-home=/usr/lib/jvm/java-11-openjdk-amd64/
--enable-release-build
Change-Id: I6c4d47b7e96232f44cb310badb18a8a30b585de8
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146117
Tested-by: Jenkins
Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
|
|
So disable it from the configure & make sure it is not brought in by the
non-iOS check.
Change-Id: I9bbf1c593d1d48197951002e04e7f925d35ecba9
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146034
Tested-by: Jenkins
Reviewed-by: Jan Holesovsky <kendy@collabora.com>
|
|
since dragonbox now installs to that one, and 1.1.3 is default for the
internal case anyway since dd1610146528cba8642caad3bf72e27b9ca6c153.
Change-Id: Ibd0449b1bd1191a1872c233bfe9810af1d1215cf
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145985
Tested-by: Jenkins
Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
Tested-by: René Engelhard <rene@debian.org>
Reviewed-by: René Engelhard <rene@debian.org>
|
|
because of hb_ot_layout_lookup_get_glyph_alternates() usage, see
https://git.launchpad.net/~libreoffice/ubuntu/+source/libreoffice/commit/?h=wip/lunar-7.5&id=97d1a9d48f30394d86db0ce948c4fb8986afc701
and
https://harfbuzz.github.io/harfbuzz-hb-ot-layout.html#hb-ot-layout-lookup-get-glyph-alternates:
"Since: 2.6.8"
Change-Id: I755c42745f3bdd647fcd7c101ea7e5fde24c5a6e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145965
Reviewed-by: خالد حسني <khaled@aliftype.com>
Tested-by: René Engelhard <rene@debian.org>
|
|
Clang 15 and older default to -std=c++14, not -std=c++17 (unlike Clang 16 onwards).
This doesn't show up with GCC because GCC 11 onwards defaults to -std=c++17.
The new version of libzxing requires C++ 17, per its release notes. Adapt
the configure check accordingly to pass -std=c++17 when checking for its
headers and save accordingly if successful.
(Do this via ${CXXFLAGS_CXX11} which has the appropriate switch
for our compiler, despite its name.)
Bug: https://bugs.gentoo.org/890324
Change-Id: Iaaa8fdc05eea0e26416b605bfda8f2d831f8729c
Signed-off-by: Sam James <sam@gentoo.org>
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145479
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
Change-Id: I051b5edd5936bcb94521f88ec7a7a762c66c9283
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145419
Tested-by: Jenkins
Tested-by: Michael Stahl <michael.stahl@allotropia.de>
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
The __EMSCRIPTEN_major__, minor, and tiny macros are no longer
predefined but only defined in <emscripten/version.h>. So grep that
instead of running emcc -dM -E.
Change-Id: I2383a906f9c746784449cd4606f653ab722b54de
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/145407
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
...while latest proper VS 2022 is 17.4.3, so my Windows
--with-visual-studio=2022preview build inconsistently picked up non-preview
standard library headers, and failed
Change-Id: I0c198d0f2e848b45afd5ffd09443d9643831f15a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144734
Tested-by: Jenkins
Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
|
|
just some partial pieces
export TEST_SYSTEM_PRIMITIVE_RENDERER=1
and the simple drawing shapes work
Change-Id: I3e01501a1cb21ec86d6fe8f5637a23e7358ffc86
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144632
Tested-by: Jenkins
Reviewed-by: Caolán McNamara <caolanm@redhat.com>
|
|
Change-Id: I6807dddc6dbe54ec582d839e5eebd2a6375bfe6d
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143841
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
no need to plant that into the environment of every recipe. some Jenkins
Windows builders already run into "environment is too large for exec"
issue just by attempting a "xargs --show-limits </dev/null" from a dummy
rule within the make environment
Change-Id: I321fa9075532eef62a7d4e33a08c272276de717e
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144217
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
Change-Id: I850a0214d12ef6b5b9a289b34a1467dfe9d35d17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144213
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
This reverts commit 599f9836a674ec525e56fa787a800d7ed4be3383.
Reason for revert: It doesn't do anything, see 144170 for next attempt.
Change-Id: Ibccf022c574e4fe527c8435eeaa6196c36ca1c30
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144176
Tested-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
This gives us support for filesystem library
(after GCC is bumped to >7)
Change-Id: I5e497ee818de883e63e1288acfc400ebadf0cdec
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144156
Tested-by: Jenkins
Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
|
|
This already was a requirement for Windows for a few years now, and make
4.0 was released nearly 9 years ago, and it has been used in LO's build
system since it has been added 11 years ago while it was only available
in prerelease versions of make, providing an alternative workaround for
systems that didn't have make built from cvs… I guess it is finally time
to get rid of those workarounds and just require make 4.0 for everyone.
NOTE: reading files with the $(file …) function was only added with
version 4.2 of GNU make, and just using it without contents was added in
4.1, so those usages aren't supported
Change-Id: Ia1c2c86cfdbbd81f349bb9f7188299e16bdd155f
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143910
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
With ce4c154e8b254f3bcd59ea46b3db4bd3d5a26058, cui now depends on oox
generated headers, so we need to build oox too, for cross builds.
Change-Id: I1af3116ab35c5094c23db3ed3dccd90c80080cef
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143975
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
With cbfac11330882c7d0a817b6c37a08b2ace2b66f4, LOKit tries to pass
full configure line on via JSON - which, on Windows, might contain
backslashes and other nasties, so we better try to clean that up here.
Change-Id: I8314783fc6f49e9b2b374d94448ed735de39bf81
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143940
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: I7269205ecaac450123e153ea549036abd9a567d4
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143884
Tested-by: Jenkins
Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
|
|
Fixes CVE-2022-37454 and a few other ones that look less relevant
including CVE-2022-45061 and CVE-2015-20107.
Change-Id: I10fd254f7f0801d47119234bb3436874e98d8c91
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143849
Tested-by: Jenkins
Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
|
|
Change-Id: I4cc88c54d42dd141f03c46377cd5c2f2fa56ad7b
|
|
6204336cc7242ff1b0fdc26ccb7f8dd4f362fb78 added support for building installsets
in parrallel using the GNU parallel tool, this patch changes that to use make's
own parallelism, dropping the need for the external tool.
By not creating huge commandline for all packages at once/sequentially, the
workarounds to modify the PATH variable can also be dropped.
Since : is a special character in makefiles separating a target from
prerequisites delimiter in the installer-tuples has been changed to the
hyphenation point.
The dependencies on the install.phony target have been moved to the actual
installset targets (and those are .PHONY targets as well since the target file
isn't actually generatead).
Also unify the tuples for the different platforms, even if the first element is
only used for Windows.
Move the msi templates to a separate directory for the different types, so that
packaging can also be done in parallel on Windows. Move the setup back to the
makefile so it can be setup prior to running the script.
Previoulsy the script used grep to remove comments from the msi template files,
and had to use "|| true" since grep would also return error when not finding a
match/on empty files. Switch that to awk so it can run without that workaround.
Change-Id: I2f8b73e04d0f601cb0b4e2d8352a38ef9957bc17
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143679
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
The various configury options here are a bit confusing, but this works
at least for me.
Change-Id: Ic9b04d40414d7d630d5a854295ce23b6e72a724a
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143486
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
The resulting config_host.mk from running autogen.sh with just
--with-distro=LibreOfficeWASM32 is identical, so this should be safe.
Change-Id: I68ab81ba4e48c18d135a824c6158d725eb3f94da
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143395
Tested-by: Jenkins
Reviewed-by: Tor Lillqvist <tml@collabora.com>
|
|
macOS Ventura replaced the patch utility by Apple's version:
patch 2.0-12u11-Apple (as of macOS 13.0.1)
It is picker/less robust when it comes to locating matches, and absolutely
refuses to apply when the hunks are out of order. Only one patch needed
rework in the current codebase (master an 7-4 branch), and being more correct
about the locations in the files to be patched is not a bad thing either, so
accept Apple's version of patch (with a warning for now)
Change-Id: I707d00958b814307b13caf9923f1de7f3919442c
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143461
Tested-by: Jenkins
Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
|
|
If no --with-main-module option is used, don't strip either.
To switch, you need to edit the instdir/program/soffice.js . (Or
static/emscripten/soffice_args.js and re-make.)
Change-Id: I572a777134e7b29fc4896e7b094ceca521874ae1
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143396
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: Icd0face05c33bbb1b56230a59015402d5f565422
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143385
Tested-by: Jenkins
Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
|
|
Change-Id: I565f3fc512b39af5c3b2e65a5cc3109794ca25ba
|
|
Change-Id: Ia666ef09e60f1d52e813adb392a99b68008d1f21
Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143091
Tested-by: Julien Nabet <serval2412@yahoo.fr>
Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
|