summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2023-03-15Bump dconf minimum version requirementStephan Bergmann
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>
2023-03-12cross-compiling on windows needs openssl to build internal pythonChristian Lohmaier
→ 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>
2023-03-08MSVC: use the newer conformant preprocessorMike Kaganski
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>
2023-03-05tdf#153465 Add Sukapura's dark variantRizal Muttaqin
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>
2023-02-27Note that Clang consteval bugs are meanwhile fixedStephan Bergmann
Change-Id: I90b2765bdad5fe753288420b01a5395bcf22f44f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/147885 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2023-02-23Refer directly to static library files for Graphite2 and HarfBuzz on LinuxRico Tzschichholz
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>
2023-02-22vcl: Avoid the need to patch HarfBuzzKhaled Hosny
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>
2023-02-16android: Support NDK 24.x and 25.x, use NDK 25 for JenkinsMichael Weghorn
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>
2023-02-16android: Move android API level check up in configure.acMichael Weghorn
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>
2023-02-16android: Use libc++_shared path that works for NDK 25, tooMichael Weghorn
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>
2023-02-16android: Use actual Android API level for minSdkVersion, nssMichael Weghorn
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>
2023-02-16android: Require NDK 23 and use default linker lldMichael Weghorn
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>
2023-02-16android: Switch from GNU binutils to support NDK 23.x, require 21.xMichael Weghorn
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>
2023-02-10qt6 configure: Search for Qt 6 moc in more locationsMichael Weghorn
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>
2023-02-10qt6 configure: Add moc version checkMichael Weghorn
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>
2023-02-09Require HarfBuzz 5.1.0Khaled Hosny
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>
2023-02-09Enable opening of downloaded fonts only in ForKit in OnlineTor Lillqvist
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
2023-02-09tdf#153476 Disable MS telemetry in VsDevCmd.batHossein
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>
2023-01-27Remove support for 32-bit S390Stephan Bergmann
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>
2023-01-27Remove support for AIXStephan Bergmann
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>
2023-01-26add "LOONGARCH64" to the JAVAINTERPRETER 64bit checkLing Yang
Change-Id: Ia0d15eb3e235fbd750b818009b5168c61c6ff0ec Reviewed-on: https://gerrit.libreoffice.org/c/core/+/139549 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins
2023-01-26Upgrade mdds and orcus to 2.1.0 and 0.18.0, respectivelyKohei Yoshida
Change-Id: I288b5b54bd07d951bcc68afda7514bde730193dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/146107 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2023-01-25android: Don't warn about NDK 21 and 22Michael Weghorn
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>
2023-01-24No need for openssl in the cross build's instdir_for_buildJan Holesovsky
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>
2023-01-23update hardcoded dragonbox include to 1.1.3Rene Engelhard
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>
2023-01-22check for harfbuzz >= 2.6.8Rene Engelhard
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>
2023-01-14configure.ac: Fix build with --with-system-zxing and < Clang 16Sam James
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>
2023-01-13Fix Emscripten version check to still work with older SDK versionsTor Lillqvist
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>
2023-01-12Adapt to newer Emscripten SDKTor Lillqvist
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>
2022-12-22Latest VS 2022 Preview is 17.5.0 nowStephan Bergmann
...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>
2022-12-21initial Experimental System-Dependent PrimitiveRenderer for CairoCaolán McNamara
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>
2022-12-20Rename function to match what it does and remove obsolete commentAurimas Fišeras
Change-Id: I6807dddc6dbe54ec582d839e5eebd2a6375bfe6d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143841 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2022-12-15don't export entries from download.lst - only used by makeChristian Lohmaier
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>
2022-12-15Simplify selection of iOS SDK, like we now do for macOSTor Lillqvist
Change-Id: I850a0214d12ef6b5b9a289b34a1467dfe9d35d17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144213 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2022-12-14Revert "Add oox to build side, for cross compilation"Michael Stahl
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>
2022-12-14Bump minimum macOS to 10.15Ilmari Lauhakangas
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>
2022-12-13bump minimum make version to 4.0 (for $(file …) function)Christian Lohmaier
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>
2022-12-12Add oox to build side, for cross compilationThorsten Behrens
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>
2022-12-11Replace backslashes in config params before usage in cxx filesThorsten Behrens
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>
2022-12-09configure.ac: update links to avoid redirects, fix broken links.Aurimas Fišeras
Change-Id: I7269205ecaac450123e153ea549036abd9a567d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143884 Tested-by: Jenkins Reviewed-by: Adolfo Jayme Barrientos <fitojb@ubuntu.com>
2022-12-09python3: upgrade to release 3.8.16Michael Stahl
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>
2022-12-08bump product version to 7.6.0.0.alpha0+Christian Lohmaier
Change-Id: I4cc88c54d42dd141f03c46377cd5c2f2fa56ad7b
2022-12-06build installer packages with make parallelism instead of GNU parallelChristian Lohmaier
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>
2022-11-30Make it possible build for WASM with --disable-gui, without Qt5Tor Lillqvist
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>
2022-11-30Move Qt5 and scripting options for Emscripten to the distro-configs fileTor Lillqvist
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>
2022-11-29accept Apple's patch utility - pickier than GNU patch, but should be OKChristian Lohmaier
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>
2022-11-29Make it possible to run either Writer or Calc in the same Emscripten thingTor Lillqvist
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>
2022-11-28Disable languagetool for WASM buildThorsten Behrens
Change-Id: Icd0face05c33bbb1b56230a59015402d5f565422 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143385 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2022-11-25bump product verion to 7.5.0.0.alpha1+Christian Lohmaier
Change-Id: I565f3fc512b39af5c3b2e65a5cc3109794ca25ba
2022-11-22Fix typoAndrea Gelmini
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>