summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2020-10-21Accept iOS SDK 14.1Tor Lillqvist
Change-Id: I093ee0a6cb6483a8891dd9ed4576da0108303c66 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104586 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-10-21Add "freebsd_powerpc" and "freebsd_powerpc64" platforms to configure.ac.Gleb Popov
Change-Id: If21b074c7a9f5da45101866ee071967bdc668af9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104561 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-20Allow to opt in for --enable-gtk3 plus --without-system-cairoStephan Bergmann
This check had been introduced with 5ad60c5d69042a73d7a1632d3c04e15783817db4 "more configure, and scp2 pieces for gtk3 integration", but without stating any reason. In a comment at <https://gerrit.libreoffice.org/c/core/+/104549/1# message-4b5fcbdabf9c7e40782df682d68efb6282b37c6e> "Allow to opt in for --enable-gtk3 plus --without-system-cairo", mmeeks now states: "My recollection is of horrors with the internal cairo being linked before the system one, and being older - such that various gtk3 themes / bits of functionality which would now link to an older (or even newer ;-) internal cairo randomly stop working / crash / burn / etc." However, at least my Linux build appears to work fine with (among others) --enable-gtk3 --enable-gtk3-kde5 --without-system-cairo And that combination proved useful to me when I wanted to run SAL_USE_VCLPLUGIN=gtk3 LO against a libcairo built with ASan the other day. So, while keeping the default of implicit --with-system-cairo if any of --enable-gtk3 or --enable-gtk3-kde5 is (implicitly) set, lets allow to nevertheless explicitly opt in to that combination---with a prominent warning. Change-Id: Ie5231085966a4f3e35b080ca162d8b846cc1ad34 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104549 Reviewed-by: Michael Meeks <michael.meeks@collabora.com> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-10-20Do not check for GNU patch utility on FreeBSD.Gleb Popov
While FreeBSD patch is indeed not a GNU one, it is sufficient to build LO. Change-Id: I55783f5bc7b4e2886e31936a317f52916d9a1e5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104519 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-10-19Add FreeBSD to the list of OSes that have OpenSSL in its base.Gleb Popov
Change-Id: I9ebbaf78c06e23f1fc44d9b97547c0a5c990cd11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104482 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-10-17fix build with box2d 2.4.0Rene Engelhard
Change-Id: I60f25f04e2bfcdabf832f42b44ba3d945f4ec169 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104456 Tested-by: Jenkins Tested-by: René Engelhard <rene@debian.org> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-16Rename CLANG_CC, CLANG_CXX configuration vars (avoid clash with scan-build)Stephan Bergmann
Clang's scan-build tool uses the CLANG_CXX environment variable (setting it up in the scan-build script to pass it to the ccc-analyzer script), but happens to erroneously set it to a non-existing path (see <https://reviews.llvm.org/D89481> "[scan-build] Fix clang++ pathname again"). So wrapping LO's autogen.sh and make in scan-build picked up that broken CLANG_CXX and caused build failures like > [CXX] external/skia/source/SkMemory_malloc.cxx > /bin/sh: ~/llvm/inst/bin/clang-12++: No such file or directory (see <https://lists.freedesktop.org/archives/libreoffice/2020-October/086113.html> "Re: llvm/clang static analyzer reports"). So rename CLANG_CXX, and for consistency also CLANG_CC and the various CLANG_CXXFLAGS_INTRINSICS_*, by prefixing each with LO_. Change-Id: Ib41cabe940f8bfb1997f74e865cca5725f859e07 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104383 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-15Fix check for inclusion of <sys/sysmacros.h>Stephan Bergmann
30a5d201144cba04dd708c11d87cc5517c04c0c3 "Do not include <sys/sysmacros.h> header unconditionally, but perform a check for it in the configure script" had added an AC_DEFINE without a corresponding mention in any config_host/config_*.h.in (we use AC_CONFIG_HEADERS), so the #ifdef was always false. The #include <sys/sysmacros.h> had been added with 01bf741a79241829b0d5c048e8f45e3cf6914d3e "WaE: include needed header" for the declaration of a major function, but which is only used in #ifdef LINUX code anyway. Change-Id: I81b574c4a3e5fa2ef4e64a507b4841044217409b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104351 Tested-by: Tor Lillqvist <tml@collabora.com> Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-10-15Do not include <sys/sysmacros.h> header unconditionally, but perform a check ↵Gleb Popov
for it in the configure script. This header is missing at least on FreeBSD. Change-Id: Iecb8c35e2ea8af84cf1488334a4d39ba0b5af7e0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104214 Tested-by: Jenkins Reviewed-by: Samuel Mehrbrodt <Samuel.Mehrbrodt@cib.de>
2020-10-09Allow CXX_X86_BINARY to be passed into autogen.sh againStephan Bergmann
...after 114ed73a7ba56e013e6d7f886798915fb20c0946 "WIN drop --enable-64bit to select Windows target" had broken a6c22d4e086957b743a135163c71ac233062619e "Allow CXX_X86_BINARY to be passed into autogen.sh" (and see the commit message of the latter commit for how this is used by builds with clang-cl) Change-Id: I7247e41a77d4f65ccae4e0ee522792646068e7b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/104101 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-10-07raise min version of gtk to 3.20.0Caolán McNamara
Change-Id: I7e463f48dabbcc27b0d5533fa2c46610cbd7aa82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103901 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-05Pre-set the host and build platform on WSLTor Lillqvist
WSL is otherwise detected as Linux, which it of course is, but on WSL we typically (?) don't want to build LibreOffice for Linux, but for Windows. Do this only if no explicit host platform has been passed on the command line. We do want it to be possible to actually build for Linux on WSL, too. For WSL, define an emulation of the cygpath command on Cygwin. Also add a simple "test" for it, for visual inspection, not an actual unit test. Change-Id: I9d9fd8f8039692d754fb96762ed00727e97130b6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103936 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-10-05Small cleanup of shell functionsTor Lillqvist
Use "local" for local variables. Document the (global) variables used to return values. Change-Id: Iadb567af9e19a627da616f05a5dc650af1c070de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103926 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-10-04Don't forward JDK home option to the cross-buildJan-Marek Glogowski
The configure flags on the command line always specify the host config, so it doesn't make any sense to forward this setting in case of a cross build. You can add a --with-jdk-home=... to the --with-build-platform-configure-options flags, if the build config finds the wrong build JDK. Also add this info to the --with-jdk-home help. For convenience (and because I don't want to adapt tinderboxes again), this forwards the host JDK to the build for Android. And explicitly disables Java for iOS build tools, as it used to be. The whole --with-java handling should probably be removed in favour of the --with-jdk-home. Do we have a real use case, where we just need the Java interpreter but not the JDK (ok - the document validators come to mind, but then you could also just simply provide a JDK...)? Change-Id: I328a15c090001bb025f4ba66d13b0cd020991fa9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103878 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-04skia: don't fail Windows Arm64 build without clangJan-Marek Glogowski
Since commit 77ba9a095b0b3f429e006571e16f8320ba0bb61e we build Windows Arm64 with Skia, but since there is no clang compiler for Arm64 in VS2019, we use the normal MSVC one. So don't even try to detect it currently. Change-Id: I1e82a1a92bce3b8f52fe24e3095ab6e70a7a1256 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103924 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-10-04Replace "newlined" sed with trJan-Marek Glogowski
This doesn't filter the list on Windows Cygwin, resulting in a lot of wrong stuff in the BUILD_TYPE, which actually isn't build. Since the next line uses tr, use this here too. Regressed-by: d4105c8aec2e1815aa536c50bc742dd5c8bff940 Change-Id: I750bd1bd5084ff5a23b4635f3ee63f46ba1dd83f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103871 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-10-04Document what PathFormat doesTor Lillqvist
Change-Id: If8b0ca9b55fb601bc3da2172f5acc00a7d83ea85
2020-10-02gpgme, coinmp, firebird: disable on Windows Arm64Jan-Marek Glogowski
There is currently no gpgme package for Arm64, coinmp uses MSbuild, which probably just needs an additional ARM64 build target via VS. Firebird configure fails with cross-build errors, and I simply stopped early trying to fix them. I'm actually wondering, why LO doesn't use the VS solutions to build Firebird on Windows. Change-Id: I3acbe91e1df287afd557a07b48e3db46b31e6d95 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103781 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-30use -fpch-codegen rather than -fmodules-codegenLuboš Luňák
The -fmodules-codegen flag has been in Clang for quite a while, but it officially works with PCHs only with Clang11+, and even there's it's better to use the properly named -fpch-codegen. This also fixes a problem with Clang9 having only -fmodules-codegen but not the -fno-* variant, causing the build to break. Change-Id: I9a8c979426f95e8c1f77cbeab1df64390d7243b8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103677 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-28upload libmwaw 0.3.17David Tardon
Change-Id: I24c6c5a5d93a76a9fcc2213cd48beb8e5a5ca479 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103519 Tested-by: Jenkins Reviewed-by: David Tardon <dtardon@redhat.com>
2020-09-27upload libwps 0.4.12David Tardon
Change-Id: Ib787098b98f68185c1b3f6b414efbec36cad02dd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102332 Tested-by: David Tardon <dtardon@redhat.com> Reviewed-by: David Tardon <dtardon@redhat.com>
2020-09-24Use -flto=thin in gb_LTOFLAGS for Apple's Clang (for macOS and iOS)Tor Lillqvist
Don't add any LTO flags into $CC and $CXX as we don't do that for other platforms either. But maybe we should? Currently, with the separate gb_LTOFLAGS, we have to handle each external project separately to make it build with LTO. Change-Id: I9761426585ebdfd976c74168218bd26bcc0e8517 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103351 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-09-23fix disable qrcodegen optionCaolán McNamara
Change-Id: Ic554f01125653022987c70d03c8c9d86fe3f547a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103271 Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-23tdf#128136: Build curl, nss, and xmlsec for iOS, tooTor Lillqvist
We must link nss statically, including the three dylibs that normally are loaded at run-time, because including bare dylibs in an iOS appp on the App Store is not OK. See https://developer.apple.com/forums/thread/125796 . For linking the softokn3 library statically, NSS already had code, behind NSS_STATIC_SOFTOKEN ifdefs. Introduce two more macros: NSS_STATIC_FREEBL for the freebl library and NSS_STATIC_PKCS11 for the nssckbi library. Turn off parallelism for the sub-make building nss. There seems to be race conditions or something when running simultaneous instances of the nsinstall.py script or the nsinstall program in nss (used when building nss for the build platform). When cross-compiling from macOS, use python3 to run the nsinstall.py script, as it is Python 3. Change-Id: Idd427b5ebf21f802b3feb0d5a3d259317ba8fc67 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103106 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Tor Lillqvist <tml@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103218 Tested-by: Jenkins
2020-09-22Use sed syntax that isn't GNU-specificTor Lillqvist
Fix fallout from 63972e79bbb9ea9654e755381641052632b0402c. Change-Id: Ie11514eb396fdc68e05ee180322df27e29ede03f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103216 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-09-21add an explicit --disable-qrcodegen configure optionCaolán McNamara
Change-Id: If8e965fa955aecdb9e7011bdddc690de9cad0c4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/103120 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2020-09-19It presumably is $LIBO_VERSION_SUFFIX that we want hereTor Lillqvist
Not $LIBO_VERSION_SUFFIX_SUFFIX. Follow-up to 271297d4fa4a8e045b6dc04942966a1058bed45c. Change-Id: I6356c84355e0ceac6e0ff492596e30a641935633 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102283 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-09-18twain32shim: disable for Windows Arm64 buildJan-Marek Glogowski
I know the platform can emulate x86 code, but have no idea, if this would include x86 TWAIN32 drivers, so disable the build for now. Change-Id: I22cb2ab81ade9f91097586f382cdd4855e27d827 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102955 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-16configure + gbuild: handle Windows Arm64Jan-Marek Glogowski
Change-Id: Idfc20c1234d693d6b402158b8bc782bd17cd3f4b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102850 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-15disable Clang's -fmodules-codegen for Skia if optimizing itLuboš Luňák
Skia is explicitly made to build optimized even in debug builds, unless --enable-skia=debug is given, so $(PCH_MODULES_CODEGEN) gets set even for it by com_GCC_class.mk , although normally it's disabled for optimized builds as not worth it. Explicitly disable the flag for Skia. Change-Id: Icf030f0bdc99dbc476af585937c864f951d2b7ca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102674 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-09-15Set PYTHONWARNINGS to error by default for --enable-werrorMike Kaganski
Setting it in environment overrides this setting. The rationale is to avoid introducing warnings like these appeared recently: zipfile.py:1517: UserWarning: Duplicate name: 'cmd/ar/sc_bulletsandnumberingdialog.png' (see e.g. https://ci.libreoffice.org/job/gerrit_windows/71910/consoleFull) Change-Id: I8ae42e039ec3d028c01dbc4bcf422feae9e46271 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100268 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-09-15cross-build: JAVA_HOME is now build, not hostJan-Marek Glogowski
Miklos reported a Android configure error, which tried to run autogen.sh for gb_Side=build, which is correctly forbidden. I checked all the files timestamps for $(BUILDDIR)/config_host.mk target - all ok, and somehow missed the JAVA_HOME test... Since my commit 42aeb9f906ca4e23d118ff8563184f9315ef3b82 ("cross-build: fix Java NI linking"), JAVA_HOME just makes sense for the build side. So the tests just make sense for the host side, if there was a --with-jdk-home supplied. This results in a sensible, empty JAVA_HOME for the host side and all Java builds I found already override JAVA_HOME with JAVA_HOME_FOR_BUILD. Change-Id: I1742a83466af70804f1700a1ca0cb6b6b77a7b12 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102676 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-12Upgrade liborcus to 0.16.0.Kohei Yoshida
Change-Id: Iae29fb26417dfc161698a81bee84e81545969065 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102502 Tested-by: Jenkins Reviewed-by: Kohei Yoshida <kohei@libreoffice.org>
2020-09-12non-cross: set Java FOR_BUILD variablesJan-Marek Glogowski
Seems I never had some JAVA_HOME ponting to some different Java, then my build system. At least that is my guess from the lo_callgrind_linux Jenkins build. Change-Id: I4315ff64064463edf34f0f96006ae72f80f1ffa4
2020-09-11cross-build: fix Java NI linkingJan-Marek Glogowski
LibreOffice has a JNI component on Windows and Linux, the officebean. Therefore we need a host JDK for linkage to the jawt, and a build JDK to compile the Java code. Change-Id: I4138628ab3ea2ef5900a5b4e9281050ae84e4eb5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102483 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11Fix naming in configure.acJan-Marek Glogowski
Regression from commit 63972e79bbb9ea9654e755381641052632b0402c Change-Id: Icb8e4aa7c1c837640c61334f7a0983a771a43df6
2020-09-11WIN cross: fix gpg-related library buildsJan-Marek Glogowski
Cross compiling these libraries requires to supply the cross- compiler via the CC_FOR_BUILD environment variable. Since we have to use the gcc-wrappers, we now need two different invocations with different inclues and libraries, but just have fixed environment variables. Also, the CC_FOR_BUILD clashes with LO's own variant, but that is easy to fix. So this change includes: - gcc-wrappers: new option --wrapper-env-prefix to add a prefix to the environment variable names - gcc-wrappers: new option --wrapper-print-cmdline to dump the real command called, when a verbose build is executed - gcc-wrappers: default to exe, if the output has no extension - unify build flags for gpg related libraries Change-Id: I4e6a6ba3c6e09237c8ffefa40ce61131290a3852 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102482 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11Fix the minimal build-tools targetJan-Marek Glogowski
The revert commits change the build-tools target for a DESKTOP build to build the complete LO. This restores the original, minimal one and also adds a whitelist of allowd build types. OpenCL needs a configure switch, as it's status is also stored in a config header, so preventing the build is not enough. This also reverts: - commit 802161a505272732566210e9ebbd8fe1b23fb86d - commit 02d931a59e2966d0c2736db8dee7be3e3dcd6bae Change-Id: Ibfcb0c54e72da1b7c2e63c082ea6586520a787fa Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102480 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11WIN drop --enable-64bit to select Windows targetJan-Marek Glogowski
This changes the Windows build to use the default configure switch to select the target / host of the compiled binaries to get the possibility to cross compile on Windows the "default" way. Note that selecting i686-pc-cygwin on x86_64 doesn't do a cross- compilation, as no special build tools are needed, because x86_64 can run x86 binaries just fine. A consequence of the change is the default target host, which is now the same then the build system, instead of the previous x86 default. Change-Id: I5584f34f665573ebac40d5d7753d96addeb84dbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102479 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11Add a MariadDB configure optionJan-Marek Glogowski
The code is already disabled on iOS and Android, so this just allows changing this setting on all platforms via configure. Also needed for the "minimal" build-tools setup. Change-Id: I590fda4cdc63b58fc17dcfb9da49c75c858b8fc0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102477 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-11cross-compile: fix PATH handling for hostJan-Marek Glogowski
Reading and exporting the PATH variable will result in a bunch of error, so we have to work with full patch when using the grep and sed commands. Since we just want the PATH for the rest of the host config run, we can simply restore it. Change-Id: I970f3bddece01c1f20ab9db7d55569e5df190675 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102476 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2020-09-09Fix AC_RUN_IFELSE for cross-compilation buildsStephan Bergmann
Regression introduced with ad6ef813e9d745d44719dae381d64cdcc2f82719 "Guard against some GCC consteval bug". Change-Id: Ie2853b0b391425faf0ae6a956c56df3002ee73bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102333 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-09Guard against some GCC consteval bugStephan Bergmann
...that caused CustomTarget_idlc/parser_test to fail with recent GCC and --with-latest-c++ with > workdir/CustomTarget/idlc/parser_test/in.idl:2 [26:26] : illegal redefinition in scope 'comsunstaruno', 'comsunstarunoXInterface' > instdir/sdk/bin/idlc: detected 1 errors > instdir/sdk/bin/idlc Version 1.1 > > Compiling: workdir/CustomTarget/idlc/parser_test/in.idl > "constructor.tests 20" expected SUCCESS, got 1 (256): FAILED! because > const OStringLiteral sGlobal("::"); in idlc/source/astdeclaration.cxx is apparently not initialized properly when the OStringLiteral ctor is marked as consteval. (See the linked GCC bug report for further details.) Change-Id: I44c547fb990c9b13d86b990199ae93e9fbe9d156 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102318 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-08The current macOS beta for Apple Silicon is 11.0Tor Lillqvist
Change-Id: I79a62c680bdf1b8d0e982fa0d30f019a9a57f666 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102251 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-09-08Follow the rules when building for the App StoreTor Lillqvist
Apple does enforce that CFBundleVersion and CFBundleShortVersionString consist of three integers. So make sure that is the case when building for the App Store. (We infer that when using --enable-macosx-sandbox we are building for the App Store. So far that is true.) Change-Id: I677b28f65aa9be9466811a982023e0932dce0893 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102237 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-09-08Use PRODUCTNAME_WITHOUT_SPACES for SDKDIRNAMETor Lillqvist
Change-Id: I2e3e45ffba563dc1b13b3b66346debd9690d0abe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102211 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-09-07Android: re-enable pdfiumMiklos Vajna
This was disabled by accident at some stage, the original commit b6f9eeb9b5c0e29ca655185dc299ebd4a2c092d7 (external: bundle pdfium, 2017-02-08) did have Android enabled back then. Change-Id: Ia875ba6c663d74e6c9061f4ffe814bc124431abe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102155 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2020-09-07Android apparently needs -lm in LIBXML_LIBS for --without-system-libxml2Stephan Bergmann
After a574bb602031f0d1febb059c7dc9d1c4937271c6 "external/redland: Honour LIBXML_CFLAGS/LIBS in raptor's configure", ExternalProject_raptor started to fail on Android with > configure: error: libxml2 is not available - please get it from http://xmlsoft.org/ due to > configure:11263: checking for xmlCreatePushParserCtxt > configure:11263: .../android-ndk/android-ndk-r20b/toolchains/llvm/prebuilt/linux-x86_64/bin/clang -target aarch64-linux-android21 -no-canonical-prefixes -ffunction-sections -fdata-sections -Qunused-arguments -o conftest -O -fvisibility=hidden -I.../workdir/UnpackedTarball/libxml2/include conftest.c -L.../workdir/UnpackedTarball/libxml2/.libs -lxml2 >&5 > .../workdir/UnpackedTarball/libxml2/.libs/libxml2.a(xpath.o): In function `xmlXPathFormatNumber': > xpath.c:(.text.xmlXPathFormatNumber+0x3d4): undefined reference to `log10' > .../workdir/UnpackedTarball/libxml2/.libs/libxml2.a(xpath.o): In function `xmlXPathStringEvalNumber': > xpath.c:(.text.xmlXPathStringEvalNumber+0x3e0): undefined reference to `pow' > xpath.c:(.text.xmlXPathStringEvalNumber+0x69c): undefined reference to `pow' > .../workdir/UnpackedTarball/libxml2/.libs/libxml2.a(xpath.o): In function `xmlXPathModValues': > xpath.c:(.text.xmlXPathModValues+0x144): undefined reference to `fmod' > .../workdir/UnpackedTarball/libxml2/.libs/libxml2.a(xpath.o): In function `xmlXPathCompNumber': > xpath.c:(.text.xmlXPathCompNumber+0x394): undefined reference to `pow' > xpath.c:(.text.xmlXPathCompNumber+0x62c): undefined reference to `pow' > clang: error: linker command failed with exit code 1 (use -v to see invocation) in workdir/UnpackedTarball/raptor/config.log, and the old way of unconditionally re-determining LIBXML_LIBS in workdir/UnpackedTarball/raptor/configure via `$XML_CONFIG --libs` had set it to > -L/data/sbergman/lo-android-aarch64/core/workdir/UnpackedTarball/libxml2/.libs -lxml2 -lm which differs from the value hardcoded in configure.ac in the trailing "-lm". Change-Id: Ifc4a70e014a826a38ad92125b6851d40e15c3c7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/102154 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-09-02Accept iOS SDK 13.7Tor Lillqvist
Change-Id: I393e96f490f3b3f69f8738fa9b552d19ec36a24d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101897 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-09-02Turn OStringLiteral into a consteval'ed, static-refcound rtl_StringStephan Bergmann
...from which an OString can cheaply be instantiated. The one downside is that OStringLiteral now needs to be a template abstracting over the string length. But any uses for which that is a problem (e.g., as the element type of a containers that would no longer be homogeneous, or in the signature of a function that shall not be turned into a template for one reason or another) can be replaced with std::string_view, without loss of efficiency compared to the original OStringLiteral, and without loss of expressivity (esp. with the newly introduced OString(std::string_view) ctor). The new OStringLiteral ctor code would probably not be very efficient if it were ever executed at runtime, but it is intended to be only executed at compile time. Where available, C++20 "consteval" is used to statically ensure that. The intended use of the new OStringLiteral is in all cases where an object that shall itself not be an OString (e.g., because it shall be a global static variable for which the OString ctor/dtor would be detrimental at library load/unload) must be converted to an OString instance in at least one place. Other string literal abstractions could use std::string_view (or just plain char const[N]), but interestingly OStringLiteral might be more efficient than constexpr std::string_view even for such cases, as it should not need any relocations at library load time. For now, no existing uses of OUStringLiteral have been changed to some other abstraction (unless technically necessary as discussed above), and no additional places that would benefit from OUStringLiteral have been changed to use it. sal/qa/rtl/strings/test_ostring_concat.cxx documents some workarounds for GCC bug <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96878> "Failed class template argument deduction in unevaluated, parenthesized context". Those places, as well as uses of OStringLiteral in incodemaker/source/javamaker/javaoptions.cxx and i18npool/source/breakiterator/breakiterator_unicode.cxx, which have been replaced with OString::Concat (and which is arguably a better choice, anyway), also caused failures with at least Clang 5.0.2 (but would not have caused failures with at least recent Clang 12 trunk, so appear to be bugs in Clang that have meanwhile been fixed). This change also revealed a bug in at least recent Clang 12 trunk CastExpr::getSubExprAsWritten (still to be reported to LLVM), triggered at least in some calls from loplugin code (for which it can be fixed for now in the existing compat::getSubStringAsWritten). A similar commit for OUStringLiteral is planned, too. Change-Id: Ib192f4ed4c44769512a16364cb55c25627bae6f4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101814 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
generated by cgit (git 2.34.1) at 2025-02-24 16:28:17 +0000