summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
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>
2020-08-26Only check X11/Intrinsic.h when $ENABLE_JAVAMike Kaganski
See Stephan's comment at https://gerrit.libreoffice.org/c/core/+/101341/2/configure.ac@10059: > that file is only compiled (via bean/Module_bean.mk -> bean/Library_officebean.mk) > when ENABLE_JAVA, so that should arguably be reflected here Change-Id: I648543cd7b71b88a29fd52483f2d97e53d3c23dc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101374 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-08-25Check for X11/Intrinsic.h required by officebeanMike Kaganski
Change-Id: I49b6868c2896c4aa5a70c2517c2f35f3ea475f2b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101341 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2020-08-19Allow to set LO_ELFCHECK_ALLOWLIST in autogen.inputStephan Bergmann
(To minimize disruption with other people's potential use of the variable, when it is not set during configuration make sure not to export it as empty from config_host.mk, so that it can then still be passed as an environment variable to individual `make` invocations.) Change-Id: I785910f1076c05905e354ef846d16ffb7ea0a081 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101002 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-18make --enable-ccache affect also CLANG_CC/CXXLuboš Luňák
Change-Id: I743ef8cc00eb605ee20da5d9524a5a46ed841e3b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100865 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-08-12Sukapura is MPL, says icon-themes/sukapura/LICENSETor Lillqvist
Change-Id: Ib4e6c5aa423f531c3826c66fb68dbe8149dce0c1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100563 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-08-12Enable --enable-lto --enable-skia when building with GCC+Clang on LinuxStephan Bergmann
...where all the Library_skia objects are built with Clang, so contain intermediate LLVM bytecode, but were then linked via GCC and ld or gold, which do not understand such object files and thus failed. So in gb_LinkTarget__command_dynamiclink use T_CC/T_CXX also for the linker command line. But then Clang would still be used for linking with the -fuse-ld=(ld or gold) $(USE_LD) suitable for GCC, and would still fail. So break T_USE_LD out of T_LDFLAGS and let gb_LinkTarget_use_clang override T_USE_LD with CLANG_USE_LD. At least for now, that CLANG_USE_LD (containing something like -fuse-ld=lld or -fuse-ld=lld --ld-path=... for the latter see d668c9a04d04d256fcbbd2165fe226f1db88256b "Adapt --enable-ld to Clang 12 trunk --ld-path") needs to manually be passed into autogen.sh, it is not computed in configure.ac. Then building Library_skia would still fail to link against StaticLibrary_libpng, as that only contains intermediate GCC object code, so make sure to build it with -ffat-lto-objects in this specific case. Change-Id: I0a104e53a8898cd9c2eb3b643e21954e853608cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-08-08bump libnumbertext requirement to >= 1.0.6Rene Engelhard
because otherwise Test name: SwUiWriterTest::testTdf133589 equality assertion failed - Expected: 𐳥𐳋𐳓𐳉𐳗 - Actual : székely 0 Failures !!! Run: 305 Failure total: 1 Failures: 1 Errors: 0 happens with (system-)libnumbertext 1.0.5 Change-Id: Ibbb33f41840b239c58e80c2a1a2c8ff5d41df58a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100342 Reviewed-by: László Németh <nemeth@numbertext.org> Tested-by: Jenkins
2020-08-07Use 10.16, not 11.0, as the minimum macOS on arm64 for nowTor Lillqvist
Change-Id: I5563d1e6f88a561fe861f6f9b0cbcbe4224ad110 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100280 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-08-07Update config.{guess,sub} with latest versions and handle fallout of thatTor Lillqvist
From http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.guess;hb=HEAD and http://git.savannah.gnu.org/gitweb/?p=config.git;a=blob_plain;f=config.sub;hb=HEAD . This time, do not apply the add-on change from 25a09c8776cc6088a5b2bf13dc84eb386c26bb7e to config.sub, but keep it pristine. Instead, let's start using the name "aarch64" instead of "arm64" for macOS and iOS in the autofoo context, as that is what those tools call it. Clang and Apple call it arm64, though. Change-Id: I1e05866c5fb08e0800cdfeaf7f6a71bfb43d1777 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100272 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-08-07Make help message match actual option nameTor Lillqvist
Change-Id: Icd959b2e221402779ff998aa249ffa4da55cdfd4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100279 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-07-29Port to FreeBSD aarch64miki
Change-Id: Ib18894db8c2943dd1502c96951545bb75a1944eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91978 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-07-29WIN fix detection of user-passed, wrong 32bit JDKJan-Marek Glogowski
If you pass an explicit JDK using --with-jdk-home, this would always test the registry value for the 32 bit test. Change-Id: If295964c5a594af26fa98ba9f4b302a6c8e7e45a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/99686 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
generated by cgit (git 2.34.1) at 2025-02-04 10:10:33 +0000