summaryrefslogtreecommitdiff
path: root/configure.ac
AgeCommit message (Collapse)Author
2024-03-02Allow building with Java 8Fridrich Štrba
Change-Id: Ib1af1a98993aabb8a03f4ef19d8da4d9a71fdbc0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164226 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-01add accessibility to --enable-mergedlibs=moreNoel Grandin
Also (*) fix the definition of ENABLE_MERGELIBS_MORE in configure.ac (*) Remove the dummy accessible factory in vcl, it creates more problems than it solves, because code will break when trying to use it, and then I get crashes far removed from the source of the problem (failure to find the acc factory). Change-Id: I969481d5ad2cfd7104d8240fdd0dce9d285fdb61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164176 Tested-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-03-01remove mergelibs warning from configureNoel Grandin
It is now known working on Linux/macOS/Windows Change-Id: Ib529a002a88cc94798a6707af7319ce9e25aca48 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164169 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-27Fix typoAndrea Gelmini
Change-Id: I30bd7ed93eedf241fde23b35ac674d010c9e6575 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/164043 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2024-02-27Check Windows SDK versionHossein
Because of a regression in Windows SDK version 10.0.19xxxx which is now fixed in 10.0.20348, it is good to check that the required SDK version is installed: More information https://developercommunity.visualstudio.com/t/std:c17-generates-warning-compiling-Win/1249671 It is important to know that both Windows 10 and Windows 11 SDK should work. Change-Id: Ia42843cac4f94c4db9ef429714f1b9d46ba3fd09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163770 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2024-02-18Latest VS 2022 Preview is 17.10.0 nowStephan Bergmann
...while latest proper VS 2022 is 17.9.0 Change-Id: Idbd104d54dde1822957894d4f74b16e651a4c8b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163485 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2024-02-15Fix file name to rmAndrea Gelmini
Change-Id: Ic700b18004e4fb84aa1153331f02cad33e01341d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163457 Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> Tested-by: Jenkins
2024-02-15Work around some Clang PCH consteval issue by disabling HAVE_CPP_CONSTEVALStephan Bergmann
(see the links in the configure.ac check for details) Change-Id: I9a98f784f68931cb4482bc02be313d18c5464105 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163422 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-14Revert "configure: clean up not needed abseil libs for the system-abseil case"René Engelhard
This reverts commit 89a0933968e4b9160613707301d1f5dd36d97282. Reason for revert: we still need absl_inlined_vector, Linking test doesn't work, this is header-only but we should check for it being there to be sure Change-Id: I55b4d645876d7080ee41917413e02cba930c9060 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163349 Tested-by: René Engelhard <rene@debian.org> Reviewed-by: René Engelhard <rene@debian.org>
2024-02-14configure: clean up not needed abseil libs for the system-abseil caseMiklos Vajna
Noticed by Rene, found by emptying the list and then adding items back till the linker succeeded again. Change-Id: I0b68ad8c50659af2d3a9ff3abfad60990f25bd79 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163378 Tested-by: René Engelhard <rene@debian.org> Reviewed-by: René Engelhard <rene@debian.org>
2024-02-12create --enable-mergelibs=moreNoel Grandin
The existing --enable-mergelibs is in use by Linux distro people, who do not want any further mergeing because they want to be able to split libreoffice up into things like nogui, calc, writer, dbaccess, etc. So this work is to enable combining even more into libmerged for platforms like Windows and macOS and COOL, where we really want everything in one big lump of code. Change-Id: I4b268864955747d9859e16ebb569debbfc32fa78 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162999 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2024-02-12kf6: Add missing include path to fix buildMichael Weghorn
Many thanks to Andreas Sturmlechner for pointing this out on #libreoffice-dev on 2024-02-12: > [10:27] <asturm> michaelweghorn: I also had to apply a trivial > openmandriva patch to get it to build in the first place, > https://github.com/gentoo/gentoo/blob/master/app-office/libreoffice/files/libreoffice-24.2-kf6-buildfix.patch Change-Id: If86220e258336d84ffc30fd5da0f5d99dda59aff Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163237 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2024-02-11Fix quoting of [ ]Stephan Bergmann
Change-Id: I57c96fe9f72794abb4f49f63735c075a4647bd23 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163228 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-07double operator < is not a strict weak ordering due to NaNStephan Bergmann
...so recent LLVM 19 trunk libc++ in debug mode complained during CppunitTest_chart2_export2 about > ~/llvm/inst/bin/../include/c++/v1/__debug_utils/strict_weak_ordering_check.h:59: assertion __comp(*(__first + __a), *(__first + __b)) failed: Your comparator is not a valid strict-weak ordering at > 5 libsystem_c.dylib 0x0000000183279a40 abort + 180 > 6 libc++.1.0.dylib 0x00000001030f9d98 _ZNSt3__123__cxx_atomic_notify_oneEPVKv + 0 > 7 libchartcorelo.dylib 0x00000002f817f0ec _ZNSt3__135__check_strict_weak_ordering_sortedB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_RT0_ + 960 > 8 libchartcorelo.dylib 0x00000002f817e6cc _ZNSt3__118__stable_sort_implB8de190000INS_17_ClassicAlgPolicyENS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT0_SC_RT1_ + 268 > 9 libchartcorelo.dylib 0x00000002f8172a90 _ZNSt3__111stable_sortB8de190000INS_11__wrap_iterIPNS_6vectorIdNS_9allocatorIdEEEEEEN5chart12_GLOBAL__N_116lcl_LessXOfPointEEEvT_SB_T0_ + 68 > 10 libchartcorelo.dylib 0x00000002f8172820 _ZN5chart11VDataSeries15doSortByXValuesEv + 508 > 11 libchartcorelo.dylib 0x00000002f8064c44 _ZN5chart9AreaChart12createShapesEv + 1528 > 12 libchartcorelo.dylib 0x00000002f80f2ae0 _ZN5chart9ChartView28impl_createDiagramAndContentERKNS_18CreateShapeParam2DERKN3com3sun4star3awt4SizeE + 4440 > 13 libchartcorelo.dylib 0x00000002f80f77ac _ZN5chart9ChartView14createShapes2DERKN3com3sun4star3awt4SizeE + 2728 > 14 libchartcorelo.dylib 0x00000002f80f58ec _ZN5chart9ChartView12createShapesEv + 692 > 15 libchartcorelo.dylib 0x00000002f80f4598 _ZN5chart9ChartView15impl_updateViewEb + 288 But the introduced use of `std::strong_order(first[0], second[0]) < 0` then triggered a false > lo/core/chart2/source/view/main/VDataSeries.cxx:105:61: error: NullToMemberPointer ValueDependentIsNotNull ZeroLiteral -> nullptr [loplugin:nullptr] > 105 | return std::strong_order(first[0], second[0]) < 0; > | ^ so needed some hack in loplugin:nullptr. And old versions of libc++, still used at least on Android, do not have any implementations of std::strong_order. So detect those cases in configure.ac (checking for std::strong_order for double, which is what is actually being used in the code) and fall back to operator <=> for now, even if that will not provide a strict weak ordering and will thus continue to violate the requirements of std::sort. And then our venerable clang-format 5.0.0 would have broken the token `<=>` into `<= >`, so exclude include/o3tl/compare.hxx from its mis-treatment. Change-Id: I7a64a630eb5f560dce59f3ff9d51ca3d1adc70be Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163075 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-07MSVC 2022 Preview: One HAVE_CPP_CONSTEVAL blocker down, one upStephan Bergmann
While the previously known issue appears to be fixed in VS 2022 Preview 17.9.0 Preview 5.0, a new one showed up that now caused > sal/qa/rtl/oustringbuffer/test_oustringbuffer_assign.cxx(63): error C2440: '<function-style-cast>': cannot convert from 'initializer list' to 'rtl::OUStringLiteral<2>' > sal/qa/rtl/oustringbuffer/test_oustringbuffer_assign.cxx(63): note: Invalid aggregate initialization > sal/qa/rtl/oustringbuffer/test_oustringbuffer_assign.cxx(63): note: too many initializers etc. Change-Id: Ia74a8d6454bb5f15c0af4d3cf29989342f2eef7a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/163072 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-05Allow to build against a non-EMSDK Emscripten installation built from sourceStephan Bergmann
The EMSDK variable was only used to find the Emscripten version.h file, but for a build from source there would be no value it could be set to in order to find the installation's cache/sysroot/include/emscripten/version.h at the $EMSDK/upstream/emscripten/cache/sysroot/include/emscripten/version.h location where configure.ac wants to look for it. (And using the configure.ac code that does not use version.h at all wouldn't work either, as the only EMSCRIPTEN_DEFINES found with at least a contemporary emcc would be just an unhelpful __EMSCRIPTEN__=1, but no version information.) So allow to explicitly set EMSCRIPTEN_VERSION_H in autogen.input to use that for the version check. Change-Id: Ic64ecfaefb3b5830f82e577b100a6e7becc73953 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162994 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-02-05Allow qmake, moc to be explicitly set in autogen.inputStephan Bergmann
(I need that for a wasm cross-build with Qt6, where MOC6 needs to explicitly be set to the build-time moc tool, not a non-existing anyway host moc tool.) Change-Id: I4a779ccc1b12b80a2e67bbaa5cd7ec04861a5d43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162984 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-29Experimental support for latest Emscripten (and Qt6)Stephan Bergmann
What I'm after in the context of our Embind-related code is the claim at <https://emscripten.org/docs/porting/connecting_cpp_and_javascript/embind.html#memory-management>: "JavaScript only gained support for finalizers in ECMAScript 2021, or ECMA-262 Edition 12. The new API is called FinalizationRegistry and it still does not offer any guarantees that the provided finalization callback will be called. Embind uses this for cleanup if available, but only for smart pointers, and only as a last resort." However, with the recommended emsdk 2.0.31 my tests did not show any use of that finalization support. So I wanted to try with the latest emsdk 3.1.51 instead. But then, linking vcldemo failed with > wasm-ld: error: ~/allotropia-qt5/lib/libQt5Core.a(qlogging.o): undefined symbol: std::__2::__vector_base_common<true>::__throw_length_error() const etc., so I gave it a try to rather build against latest Qt6.7, with > --with-distro=LibreOfficeWASM32 > --disable-qt5 > --enable-qt6 > QT6DIR=... TODO: The result is highly experimental, and it uses ENABLE_QT5 (i.e., the recommended setup with emsdk 2.0.31 and the <https://github.com/allotropia/qt5.git> v5.15.2+wasm branch) vs. ENABLE_QT6 (i.e., my experimental setup with emsdk 3.1.51 and the <https://github.com/qt/qt5.git> 6.7 branch) not only to distinguish between Qt5- vs. Qt6-specific behavior, but also to distinguish between old- vs. new-Emscripten-specific behavior. Of note: * The startup code appears to have changed substantially (and required setting -s MODULARIZE=1 and -s EXPORT_NAME=soffice_entry now, and telling emcc to build just soffice.js and not the wrapper soffice.html. TODO: This also required hacking into qt_soffice.html: (1) The command-line arguments (--norestore, --nologo, --writer, and the exammple.odt; all of which we should eventually get rid of, anyway). (2) Saving the generated instance as window.Module (and adapting the embindmaker-generated code, cf. the changes to static/README.wasm.md). * There were some symbol clashes between external/argon2 and libQt6Core.a(qcryptographichash.cpp.o, so renamed the problematic symbols in external/argon2. Change-Id: I5420ab566d560b11954ac6613249bfc53d8acb31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162695 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-24fix windows aarch64 cross-build wrt REPORTBUILDERChristian Lohmaier
broken after a2a9850217b3f711440283131fdfc58a9a254919 which added the REPORTBUILDER conditional, but didn't also put it into the special PERMITTED_BUILD_TARGETS list - so it wasn't set during cross-compilation and broke the build C:/cygwin/home/tdf/jenkins/dly/s_master/solenv/gbuild/Configuration.mk:169: *** There is no target C:/cygwin/home/tdf/jenkins/dly/b_master/workdir_for_build/XcuModuleTarget/officecfg/registry/data/org/openoffice/Setup-reportbuilder.xcu. Stop. Change-Id: I9474318eae775bcd974e79db0d8340a2d3839412 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162504 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2024-01-23BOOST_ERROR_CODE_HEADER_ONLY doesn't do anything in boost >= 1.69Caolán McNamara
which was released on Dec 12th, 2018 https: //lists.boost.org/Archives/boost/2021/10/252209.php Change-Id: I8d65d98648a44d7303fc46338bfdeba7801749e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162423 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2024-01-22use portable "command -v" to detect installed programs, part 2Eli Schwartz
The "which" utility is not guaranteed to be installed either, and if it is, its behavior is not portable either. This means that when various programs are installed, the `which` check will report a fatal error because the which tool did not exist and the shell returned a nonzero status when attempting to fork+exec. If it did exist, it might not be an implementation of `which` that returns nonzero when commands do not exist. The general scripting suggestion is to use the "command -v" shell builtin; this is required to exist in all POSIX 2008 compliant shells, and is thus guaranteed to work everywhere. For some in-depth discussions on the topic, see: - https://mywiki.wooledge.org/BashFAQ/081 - https://unix.stackexchange.com/questions/85249/why-not-use-which-what-to-use-then/85250#85250 Examples of open-source shells likely to be installed as /bin/sh on Linux, which implement the 15-year-old standard: ash, bash, busybox, dash, ksh, mksh and zsh. This commit updates the build system to configure and build correctly on systems without `which`. Change-Id: I23dbde5c7f104dd610fd5f78c82bf9a7d0cc1930 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160663 Tested-by: Jenkins Tested-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org> Reviewed-by: Ilmari Lauhakangas <ilmari.lauhakangas@libreoffice.org>
2024-01-21Extract embindmaker from cppumaker into its own toolStephan Bergmann
...that directly generates one large .cxx Change-Id: I046539b83f8fde5eda7168c93a8b819137399665 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162343 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-16Remove unused `make upload-update-info`Stephan Bergmann
Change-Id: Ifdec48aaf53b0444c2d7ceef554f64795e2f2c38 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162172 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-15FreeBSD: evaluate --with-gnu-patchAndras Timar
Change-Id: I41e2cc8dc74022c840dac6355ed29cc0c4c40b17 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162063 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2024-01-14Fix system-libfixmathThorsten Behrens
Seems distros start to disagree on whether its liblibfixmath or just libfixmath. Change-Id: I54a42b2ba050980ae632ab3c82254131cad7787e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161969 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-13system poppler cannot be used with dbgutilThorsten Behrens
Change-Id: I88d68e85c25bdaf6f4a06e00e812ac31cd125dfe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162019 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-13system zxing cannot be used with dbgutilThorsten Behrens
Change-Id: I0b0c646f64ce103e706d8e4b1cc50f9120c4799a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161975 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2024-01-11Fix `make create-partial-info` (for Windows, at least)Stephan Bergmann
I got lost trying to figure out how the original bin/update/create_partial_update.py code was meant to obtain old and new installation trees to diff, so I simplified that down to the create-partial-info make target now expecting an ONLINEUPDATE_MAR_OLDARCHIVE make variable that points at the old archive install set. (And the --with-online-update-mar-serverurl configure option is gone for good again.) The remaining changes are similar to what was needed in 28bad382face10be75af3875e44dde89fbc78108 "Fix `make create-update-info` (for Windows, at least)". (And the mbsdiff and mar tools expect Windows-style pathnames, but mktemp returns a Unix-style pathname in cygwin shell scripts, so this needed an additional Windows-only external/onlineupdate/cygpath.patch.) Change-Id: I40690210d62e3f26fb2d574914a0dd4323e6cd62 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161924 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-03Actually drop --with-online-update-mar-channelStephan Bergmann
...which had accidentally been forgotten by 6910b1e3511701de5f0541fcaa98babf530f55ce "Hard-code --with-online-update-mar-channel=LOOnlineUpdater" Change-Id: I2dc9e500cfd9ffb1962c3fe3aa0bc9d6ba49c3d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161585 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-02Hard-code --with-online-update-mar-channel=LOOnlineUpdaterStephan Bergmann
(An upcoming change will add an instset/update-settings.ini file containing that value, but using a GeneratedPackage for a single file instead of a directory seems unsupported, so it will use the hard-coded value and a plain Package instead.) Change-Id: I12ffef4db71ce36be9096df674588b39c660e4de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161545 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2024-01-01update LIBO_THIS_YEARRene Engelhard
Change-Id: I023baa2238c6cdbbd54a7e6b0fcdb128510bbd4c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161522 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-12-23tdf#105844 argon2: add vcxproj files for WinARM64 buildsThorsten Behrens
Also add argon2 to crossbuild tools side. Change-Id: I8704b2d8362a051c2d634b9db7416cdc2cf9add4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161206 Tested-by: Jenkins Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2023-12-21get rid of warnings when reportbuilder is not configured for buildAndras Timar
In the LOK case for example, where there is no reportbuilder, there were a lot of bogus warning messages at startup, confimgr complained that there were translations for non existing configuration nodes, all belonged to reportbuilder. Change-Id: I7f9cef3206bddd9e333b97ee966fb950fbb352d2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160887 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Miklos Vajna <vmiklos@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/161048 Tested-by: Jenkins Reviewed-by: Andras Timar <andras.timar@collabora.com>
2023-12-19argon2: add new external libraryMichael Stahl
Change-Id: I81860a94b33eba95918c30b0e92b583cc2d02ff3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160969 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2023-12-18fix system-abseil build even with 2022 versionRene Engelhard
actually it seems it was a internal abseil header from pdfium vs. system header mismatch. Include proper absl/container/inlined_vector.h if using system-abseil. While at it we can also just use pkg-config, no idea why I did it without back then. Also gets the advantage that it knows that the libs needed for absl_inlined_vector is actually -labsl_throw_delegate -labsl_raw_logging_internal -labsl_log_severity This effectively reverts e89723103313ec4366ee58144c47d7a5c16bf838 Change-Id: Ide4f79860b4e0673c5c6587d503058bdd2930744 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160846 Tested-by: Jenkins Reviewed-by: Miklos Vajna <vmiklos@collabora.com>
2023-12-15check abseil versionRene Engelhard
since 918515d6fc6e2eaa000c4a997d604b7b00b492e3 updated to a pdfium version which only builds with >= 20230125.3 (earliest I could get hand on). Ideally we should test for the feature, but this suffices too and we do that for other libs, too... Change-Id: I14719186d415b9df82f607b26233c9be154492c6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160833 Tested-by: René Engelhard <rene@debian.org> Tested-by: Jenkins Reviewed-by: René Engelhard <rene@debian.org>
2023-12-15Turn onlineupdate into external/onlineupdateStephan Bergmann
...and update to latest Mozilla sources. Originally, this was a non-external onlineupdate module (plus correspsonding top-level include/onlineupdate/ directory) that apparently contained sources originally copied from Mozilla and subsequently modified in-place (plus, mixed in, presumably some sources that were not copied from Mozilla but were our own inventions). To clean up this mess, this has been turned into a proper external/onlineupdate module with a tarball containing the pristine external Mozilla sources. The sources for the onlineupdate-c003be8b9727672e7d30972983b375f4c200233f.tar.xz tarball are taken, somewhat arbitrarily, from a recent <https://github.com/mozilla/gecko-dev/commit/c003be8b9727672e7d30972983b375f4c200233f> ("Bug 1867784 - Force reflow all kids in the last column balancing reflow. r=layout-reviewers,dholbert") trunk state, by running `external/onlineupdate/generate-sources.sh ~/github.com/mozilla/gecko-dev` on a Fedora 39 machine. The layout of the tarball still mostly follows the old onlineupdate/ layout, even if that deviates heavily from the actual source layout at <https://github.com/mozilla/gecko-dev/>. (And some files, which apparently are not needed, anyway, lacked sources, see the "Missing source for" in external/onlineupdate/generate-sources.sh. And win_dirent.h/.cpp has meanwhile been superseded by updateutils_win.h/.cpp.) Merely newly included source files are laid out in the tarball according to the actual source layout. Any LO-specific modifications are made via patch files (rather than modifying the sources inline, as was done in the past): external/onlineupdate/lo.patch contains whatever modifications are needed to adapt the functionality, while external/onlineupdate/gtk3deprecated.patch fixes > workdir/UnpackedTarball/onlineupdate/onlineupdate/source/update/updater/progressui_gtk.cpp:97:21: error: use of undeclared identifier 'gtk_vbox_new'; did you mean 'gtk_box_new'? > 97 | GtkWidget* vbox = gtk_vbox_new(TRUE, 6); > | ^~~~~~~~~~~~ > | gtk_box_new to not use the deprecated gtk_vbox_new, which is hidden because we include -DGTK_DISABLE_DEPRECATED in our GTK3_CFLAGS as per our configure.ac. On Windows, the definition of __BYTE_ORDER__ etc. is needed because workdir/UnpackedTarball/onlineupdate/include/mozilla/ says "Our supported compilers provide architecture-independent macros for this", but MSVC doesn't actually, so define here what would implicitly be defined by GCC. Similarly, on Windows -U_WIN32_WINNT is needed to undo -D_WIN32_WINNT=0x0601 in solenv/gbuild/platform/windows.mk, which would cause > workdir\UnpackedTarball\onlineupdate\include\mozilla/WinHeaderOnlyUtils.h(537): error C2065: 'FILE_ID_INFO': undeclared identifier etc., despite the #include <windws.h> there. Curiously, the original gb_CustomTarget_CustomTarget,onlineupdate/generated from onlineupdate/CustomTarget_generated.mk had to be renamed to gb_CustomTarget_CustomTarget,external/onlineupdate/generated when the file was moved to external/onlineupdate/CustomTarget_generated.mk, as otherwise a top-level `make CustomTarget_onlineupdate/generated` would have failed with "No rule to make target..." Also, as there is no gb_CustomTarget_use_unpacked, its effect has been poorly mimicked for now in external/onlineupdate/CustomTarget_generated.mk. Similarly, as there is no gb_WinResTarget_use_unpacked, its effect has been poorly mimicked for now in external/onlineupdate/WinResTarget_updater.mk. The original onlineupdate/workben/test_dialog.cxx, which is actually code written by us, has been moved to external/onlineupdate/workben/test_dialog.cxx. The original onlineupdate/qa/ sources (which were apparently not used during the build) have been preserved for now as external/onlineupdate/qa/, for documentation purposes. The original onlineupdate/astyle.options (which was apparently not used during the build) has been removed. Change-Id: I5ea606202e7837269e7b128e45af2f0b8c277f9e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160492 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-12Split --with-update-config=... into many --with-online-update-mar-...=...Stephan Bergmann
...and allow each of them to be left off, for debug purposes, even if that may render the resulting --enable-online-update-mar feature non-functional. This change tracked each item that was potentially read from the --with-update-config ini file, and turned each of them into a new --with-online-update-mar-... option. The only exception and remaining TODO is bin/update/upload_build_config.py (called from Makefile.gbuild). distro-configs/Jenkins/LibreOfficeLinuxUpdater.conf (which might well be dead) set --with-update-config=~/updater.ini with an ini file of unknown content. So that no items are silently missing if we ever resurrect that distro-config, I set all of the new options to =TODO there for now. Change-Id: I17a13e0d190a868436bac10c1b0a6675d8c704c0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160622 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-11Fail when explicit --enable-ccache cannot be honoredStephan Bergmann
Change-Id: I2b638dad3e3a1f3d7044997061a8597b44067a5e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160600 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-08configure: Pass '--auto-servernum' to xvfb-run here, tooMichael Weghorn
Pass that param in configure.ac as well, to avoid multiple instances of xvfb-run potentially getting into each other's way. See the commit message of commit ca01deadcbc480b6e79618b227a2b73a61ecb7ff Author: Michael Weghorn <m.weghorn@posteo.de> Date: Mon Oct 16 11:03:46 2023 +0200 gtk3 a11y test: Let xvfb-run auto-determine free server num for more details, which added that param at the place where the tests using xvfb-run are run. Maybe this has a positive effect on occasional test failures like [1]: checking for xvfb-run... /usr/bin/xvfb-run checking whether /usr/bin/xvfb-run works...... no configure: error: xvfb-run required by --enable-atspi-tests not found Error running configure at ./autogen.sh line 321. [1] https://ci.libreoffice.org/job/gerrit_linux_gcc_release/154929/console Change-Id: Ie7ba6ec58ea44e5cf8a52d18f0359d3c2335a4ed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160466 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2023-12-08bump product version to 24.8.0.0.alpha0+Christian Lohmaier
Change-Id: If1f03b745fa3855daf18ddc531a0bf7d949d21a7
2023-12-08android: Bump minSdkVersion to 21 (Android 5.0)Michael Weghorn
NDK 26 dropped support for API levels < 21 [1] [2]. Do the same for our Android build, to ease the maintenance. Adapt configure.ac accordingly and drop the now obsolete code paths in Android Viewer Java code. This in also means that the same minSdkVersion will be used for all architectures now, while API level 21 was already used for the 64-bit variants (for which the minimum supported version was 21 anyway) and API level 19 was used for x86 and 32-bit ARM when building with NDK 24/25, API level 16 when building with NDK 23. According to [1] and [3], more than 99% of Android devices have at least Android version 5, i.e. support API level 21. [1] https://github.com/android/ndk/issues/1751 [2] https://developer.android.com/ndk/downloads/revision_history [3] https://apilevels.com/ Change-Id: I875e784dd4e62993f51059ae6a280d425cb49c0a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160334 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2023-12-07Make --enable-online-update and --enable-online-update=mar orthogonalStephan Bergmann
...by turning the latter into its own option --enable-online-update-mar. (The intention is to potentially have the experimental --enable-online-update-mar configured in alongside any traditional --enable-online-update, and have it disabled by default at runtime---for which some configuration is needed and which is forthcoming.) Change-Id: Id53b4f52b310da472b305c8b23c1e2ba1931296d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160424 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-12-07Adapt consteval failure check to recent GCC 14 trunkStephan Bergmann
...which happens to accept the original check from af34108d90bbbce90cf00c4b23961787599c7fa5 "Use C++20 consteval for the Color(sal_uInt32) ctor" now, but would still fail to compile the actual code at > In file included from xmloff/source/chart/ColorPropertySet.hxx:23, > from xmloff/source/chart/ColorPropertySet.cxx:20: > include/tools/color.hxx: In constructor ‘xmloff::chart::ColorPropertySet::ColorPropertySet(Color)’: > xmloff/source/chart/ColorPropertySet.cxx:81:9: in ‘constexpr’ expansion of ‘((xmloff::chart::ColorPropertySet*)this)->xmloff::chart::ColorPropertySet::m_nDefaultColor.Color::Color(10079487)’ > include/tools/color.hxx:82:11: error: modification of ‘*(xmloff::chart::ColorPropertySet*)this’ is not a constant expression > 82 | : mValue(nColor) > | ^~~~~~~~~~~~~~ (see the comment at <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98752#c6> "wrong "error: ‘this’ is not a constant expression" with consteval constructor") Change-Id: I3b8b92cd7ba31724cf0c9fe38b6cf8aa2abd7c0f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/160405 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de>
2023-11-23bump product version to 24.2.0.0.alpha1+Xisco Fauli
Change-Id: Iabc985c1329d4c1ac31ddf93e8b8f4b6f3c48900
2023-11-18Latest VS 2022 Preview is 17.9.0 nowTaichi Haradaguchi
...while latest proper VS 2022 is 17.8.0 Change-Id: I40905f3d79c3723796c4c9964f72d0fed73795c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159607 Tested-by: Jenkins Reviewed-by: Taichi Haradaguchi <20001722@ymail.ne.jp>
2023-11-16fix --enable-wix switch - that didn't do anythingChristian Lohmaier
it used the wrong variable name in AC_SUBST and also had no place where it would be set for the rest of the build to use. Also the script hardcodes the location of the WiX Toolkit, so check for the same path in configure. Also it was needlessly tied to LIBO_TEST_INSTALL - since it has its own conditional, "double-guarding" it is not necessary. Change-Id: I6dd4a41e63d2a43a3e2f1aac5b6799a6601eb656 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159510 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2023-11-13Fix a typoMike Kaganski
Change-Id: I95404a278b53d7021adacd99ee7482592c0eb8e7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159245 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2023-11-13upgrade libcmisCaolán McNamara
Change-Id: Ie2d5f3f8208f9952db5be10905b5905cd03b91de Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159366 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolan.mcnamara@collabora.com>
2023-11-13Re-introduce build config to version info reported by LOKMike Kaganski
... as an opt-in --with-buildconfig-recorded configure option. This allows to have the data in the admin console, as implemented in commit cbfac11330882c7d0a817b6c37a08b2ace2b66f4 (Send build config (configure options) in LOKit version info JSON, 2022-11-07), when reprobuilds are not required. The default is no build config, which is compatible with reprobuilds. This reverts commit 389def871853c885289627452f40b3ae0a8dabc8. Change-Id: I7f0be489a1c82268d0ca38cb761843c9d432a14b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/159344 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
generated by cgit (git 2.34.1) at 2025-02-10 09:52:08 +0000