summaryrefslogtreecommitdiff
path: root/config_host.mk.in
AgeCommit message (Collapse)Author
2022-10-27Enable gtktiledviewer on WindowsMike Kaganski
A new configure argument is introduced: --with-gtk3-build=<absolute path to GTK3 build> When provided, libreofficekit_selectionhandles package, libreofficekitgtk library and gtktiledviewer executable would be built on Windows using the GTK3 libraries in the passed directory, that must contain lib/pkgconfig subdirectory with correct pkg-config data. Change-Id: I6504af6eec0fc73cceb26a1ce923337abe14b5c4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141624 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/141875 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com>
2022-10-16build libtiffJulien Nabet
Change-Id: Id9b6e1355147c3f68b9922db14f1b4904a05c686 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/134650 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-08-28tdf#150452: Revert "tdf#130795 use concurrent hashmap in SharedStringPool"Xisco Fauli
This commit reverts 3749d9af3745c0eaff7239e379578e4e2af89e9d which removes the dependency on the external library cuckoo Without using cuckoo the same file in tdf#130795 takes real 0m4,892s user 0m5,298s sys 0m0,449s With it, it takes real 0m4,914s user 0m5,276s sys 0m0,444s pretty much the same time Change-Id: I4cc9000ac5bf26de22bb9835283ae8d5b3230196 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138435 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Xisco Fauli <xiscofauli@libreoffice.org> Signed-off-by: Xisco Fauli <xiscofauli@libreoffice.org> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/138446
2022-07-26allow to override PKGFORMAT when running makeChristian Lohmaier
building installation sets takes a long time, and is a .PHONY action. Having a way to skip that when running make is esp. useful with IDEs that have no nice way of separating the "run/debug" action from the build action. (XCode, looking at you and your awkward schemes…) Use with »make build PKGFORMAT=""« Change-Id: Iab0c03a4096fe5571a5496b52504b3393e9f3cf6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137111 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit ca056d8680334e48343ad2c1f6c512d7fc5bab8a) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/137067 Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2022-07-02allow to specify a macOS provisioning profileChristian Lohmaier
having one is one of the prerequisites of using TestFlight Change-Id: I9e20eb99905071fade4179dfbe2da5b7e5dd1c24 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136618 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> (cherry picked from commit b43f0b0295953c8d5d16c5b9eccaddb5ec214bab) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/136695
2022-06-09Get make_installer calls to run in parallelThorsten Behrens
If available, use GNU parallel to run N make_installer.pl scripts in parallel, to scale packaging LibreOffice up with the rest of gbuild. * fallback if no GNU parallel found - run make_installer sequentially as before * push most of the make_installer.pl input param tweaks from gbuild down into a shared call_installer.sh script * call gnu parallel with generated number of "templ:lang:prodname:ext:pkgfmt:strip-flag" tuples, one for each package to build (empty templ for non-windows, to save on cmd line length) * such that we can run all those in parallel (taking into account the build's PARALLELISM parameter) * there's still the main package build running epm sequentially for umpteen sub-packages from within _one_ make_installer.pl instance, but that's much harder to parallelize from inside Perl (so we punt on that here) Change-Id: Ie7d3084ed60d003d587c5e64dc9fb1809b23e409 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133957 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> Reviewed-on: https://gerrit.libreoffice.org/c/core/+/135346 Tested-by: Jenkins CollaboraOffice <jenkinscollaboraoffice@gmail.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2022-03-23make Calc jumbo sheets an explicit build featureLuboš Luňák
On 32bit platforms tools::Long is 32bit, which is not enough for pixel coordinates with 1m+ Calc rows+. So do not allow jumbo sheets for such platforms. Change-Id: I2ebd56a051470d33fca967918af3e7d2b0172dc7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130713 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2022-02-23eliminate ENABLE_STRIP because it causes build issues in nss (Android)Andras Timar
Change-Id: Ie229f444d80a5f441576649e22b0c56c67cd3424 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130347 Tested-by: Andras Timar <andras.timar@collabora.com> Reviewed-by: Andras Timar <andras.timar@collabora.com>
2022-02-14support for the WebP image format (tdf#114532)Luboš Luňák
This commit implements a WebP reader and writer for both lossless and lossy WebP, export dialog options for selecting lossless/lossy and quality for lossy, and various internal support for the format. Since writing WebP to e.g. ODT documents would make those images unreadable by previous versions with no WebP support, support for that is explicitly disabled in GraphicFilter, to be enabled somewhen later. Change-Id: I9b10f6da6faa78a0bb74415a92e9f163c14685f7 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128920 Tested-by: Jenkins Reviewed-by: Tomaž Vajngerl <quikee@gmail.com>
2022-02-13[cp] Allow creation of debuginfo and debugsource rpm/deb packagesAndras Timar
Change-Id: Idae5128b58e4cd6f61b8e83664098d195ca67072
2022-02-13Make installer compression tool configurableThorsten Behrens
So we can use pigz or other parallelizable tools if available. Shaves off noticeable build time when packaging install sets. - figure out if pigz is available (fallback to gzip otherwise) - pass compression tool down into make_installer - and handle as one of many global options there Change-Id: Ia9d1ea27a9f990874238b6f0be3e1fd30a662ec6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128469 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2022-01-14annocheck warning about missing .note.gnu.property sectionCaolán McNamara
copy and paste recommendation from: https://sourceware.org/annobin/annobin.html/Test-cf-protection.html and adapt like: https://github.com/openssl/openssl/commit/51994e505dbb1cd0dd76869ec962e2948b77b585 where https://bugs.ruby-lang.org/attachments/8962 is similar Intel docs have "The ENDBR32 and ENDBR64 (collectively ENDBRANCH) are two new instructions that are used to mark valid indirect CALL/JMP target locations in the program." Change-Id: Ie867c263a888763db4478720ba189c9ec6cc974d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126859 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com> (cherry picked from commit af55dc3891f7950d392175004b2090cb0e54828e) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127963 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2022-01-06Add configure test for the backtrace implementationIsmael Luceno
Improve robustness by testing explicitly; instead of assuming based on the OS, test first the libc and then test for libexecinfo. The assumption was wrong for FreeBSD (included since 2017) and for musl-based systems (not in libc). Also, remove INCLUDE_BACKTRACE and clean up a bit. Ref: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=220271 Change-Id: Ib4b7fd4fe2cdf5f76babe47a21bd2990fcf42649 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127538 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> (cherry picked from commit c1be12396088563ed77ed61e54fd4e153469701d) Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127767 Reviewed-by: Ismael Luceno <ismael@iodev.co.uk> Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-11-19add with-system-abseil/with-system-openjpeg for pdfiumRene Engelhard
Change-Id: I270cbb75cde2a44416b61978b8eefdf267720031 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125559 Tested-by: Jenkins Reviewed-by: René Engelhard <rene@debian.org>
2021-11-17support ccache for MSVC tooLuboš Luňák
There's no official MSVC support in ccache yet, but there are patches in progress of getting upstreamed. So right now it's necessary to get a patched ccache. Ccache cannot work with -Zi option, since sharing debuginfo in a .PDB cannot be cached. Added --enable-z7-symbols that gets enabled by default if ccache is detected. It works even with PCHs enabled, and externals seem to work too. I get almost 100% hit rate on a rebuild, although such a rebuild is slower than on Linux. Change-Id: I1d230ee1fccc441b9d9bec794cc2e1ec13161999 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125179 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-10Upgrade external/boost to latest Boost 1.77.0Stephan Bergmann
<https://dev-www.libreoffice.org/src/boost_1_77_0.tar.xz> has been generated (on Fedora 35) with > $ wget https://boostorg.jfrog.io/artifactory/main/release/1.77.0/source/boost_1_77_0.tar.bz2 > $ printf 'fc9f85fc030e233142908241af7a846e60630aa7388de9a5fafb1f3a26840854 boost_1_77_0.tar.bz2' | sha256sum -c # cf. <https://www.boost.org/users/history/version_1_77_0.html> > boost_1_77_0.tar.bz2: OK > $ external/boost/repack_tarball.sh boost_1_77_0.tar.bz2 > Unpacking boost_1_77_0.tar.bz2 ... > Removing unnecessary files ... > Creating boost_1_77_0.tar.xz ... > Cleaning up ... > 9b334d6c6d7af5a0687280788cd84444398b8e0b472cd88e52bbc3c3ef11d98e boost_1_77_0.tar.xz > Done. Change-Id: I527cad7eb2f311d968da371f268644bdd31f6462 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124947 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-09download.lst: define OPENSYMBOL variables like everything elseMichael Stahl
No reason why the filename should be defined in configure? Remove unused NUMBERTEXT_EXTENSION_SHA256SUM. Change-Id: I3d3084e2052cb98ddbe2c1cf10691dcc5d716d19 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124889 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-11-04Consolidate -D_GLIBCXX_DEBUG for --enable-dbgutil builds against libstdc++Stephan Bergmann
(this was meant as a prerequisite for enabling its -D_LIBCPP_DEBUG=1 counterpart when building against libc++ on macOS, but which got stalled for now after running into the issue described at <https://lists.llvm.org/pipermail/libcxx-dev/2021-October/001222.html> "[libcxx-dev] Building a program with -D_LIBCPP_DEBUG=1 against a libc++ that is not itself built with that define") Change-Id: If466dce595a9311b2afbae41d5ddcaecc6f3c57b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124678 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-11-03fix gcc-wrapper for ccache.exeLuboš Luňák
This reverts a part of 18cc01b63996f81b284e3bc827d1be7f3da8983a . Change-Id: Ib7abbc41eeb6abd573f540ae2d0d2822e68b9abb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124613 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-30upgrade libjpeg-turbo to 2.1.1Caolán McNamara
simd enabled for x86_64 and x86, arm/aarch64 might be worth exploring too Change-Id: Ic2726ee8c6b6e59ca983b977ee2731f5b78b97d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123898 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-10-27fix AVX512 detectionLuboš Luňák
The value wasn't in config_host.mk.in, so it's never been used. And also fix Calc Kahan CPU-specific code yet again :( . Change-Id: Iacfd500e5a662b2b4b96a009d129a012d278a3ad Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124248 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-11remove unused variablesLuboš Luňák
The if is even wrong, testing for WINNT nested inside testing for not WINNT. Change-Id: I797ff61099064f1b66fea34fb25a00a88df4fca2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123255 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-08Centralize VS-to-toolset mapping in configureMike Kaganski
This allows to define the mapping once, and avoid modification in multiple places each time a new VS version support is added Change-Id: I93de4c9d78c3f67a0a2e157007e9d13b6f557937 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123163 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-09-29qt6: Add a qt6 VCL pluginMichael Weghorn
This adds a new "qt6" VCL plugin based on Qt 6. Building the plugin is enabled by autogen option '--enable-qt6' (and optionally setting 'QT6DIR' as needed). Use the 'SAL_USE_VCLPLUGIN=qt6' environment variable before running LO to select this VCL plugin. Taking qt6 into account at all relevant places certainly still requires follow-up changes, but this builds and runs with a self-compiled qtbase from the 'dev' git branch as of commit 3ce0672143d2eb3c3809f82998a4d71c5800d77a. I didn't see anything obviously broken in a quick run, but didn't test much. This reuses and shares the qt5 VCL plugin code; the qt6 headers and sources for now just '#include' the qt5 ones. Version checks are used for the code places that need different handling to be built against Qt 6. The build system parts in this commit were mostly done by copying the qt5 equivalents, then adapting as needed. Some notes on things I came across while porting to qt6: 1) At least in my self-compiled Qt versions, 'moc' (the meta-object compiler) is located in the 'libexec' subdirectory in 'QT6DIR', while the Qt 5 equivalent is located in the "bin" subdirectory of 'QT5DIR', so the configure.ac check uses the former. 2) moc does not process classes from the included headers. Since the headers in 'vcl/inc/qt6' just '#include' the ones from 'vcl/inc/qt5', running moc on the qt6 headers doesn't work, so moc is currently run on the qt5 headers for qt6 as well (s. 'vcl/CustomTarget_qt6_moc.mk'). That will have to be adapted in case the qt6 VCL plugin uses "own" headers instead of just including the qt5 ones at some point. 3) QX11Extras has been removed from Qt 6. [1] says: > Changes to Qt X11 Extras > > The QX11Info class has been removed. > > Clients that still rely on the functionality can include the private > header <QtGui/private/qtx11extras_p.h> as a stopgap solution. To enable > private headers use QT += core-private with qmake, or add a project > dependency to Qt::CorePrivate with CMake. I didn't take any closer look, just dropped the use of QtX11Extras for qt6 for now. 4) XCB_ICCCM is no longer needed. It is only used in qt5 to workaround a Qt bug fixed in Qt 5.12, s. commit fe2baf9e84e0ca9aeaa683e37076f57fa3f38dca Author: Jan-Marek Glogowski <jan-marek.glogowski@extern.cib.de> Date: Tue Dec 3 08:32:58 2019 +0100 Qt5 fix missing XCB_ICCCM_WM_HINT_WINDOW_GROUP 5) X11-specific code is still used for key modifier handling. Therefore, still check for the XCB headers when 'USING_X11' is set in configure.ac, and use a 'QT6_USING_X11' define (as qt5 uses 'QT5_USING_X11'). 6) There's currently no Qt 6 video sink for GStreamer. As of today, qt-gstreamer is unmaintained and there is no Qt 6 version. The project's README [2] says: > 0. Maintenance Notice > --------------------- > > This code is unmaintained. You can use it at your own risk. > > If you want to integrate video display in your QML-based UI, > you should consider using 'qmlglsink', from gst-plugins-good. > This is a well supported video sink that uses the generic > gstreamer-gl stack and is in many ways superior to 'qtquick2videosink' > that is provided by qt-gstreamer. You can use this code as an example: > https://cgit.freedesktop.org/gstreamer/gst-plugins-good/tree/tests/examples/qt/qmlsink > > If you are not interested in using QML in your UI, then you > may use one of the other elements provided by this module > (see below). If you do that, it would be helpful to let us > know that this code is still useful to you. We may consider > adding these elements in one of the core gstreamer modules. > > If you are here for the Qt-style bindings, I'm sorry to disappoint you. > The alternative is to use the C API, or the GStreamermm C++ API. > Qt-style bindings are cool, but unfortunately they are very hard > to maintain because they are written by hand. If you are interested > in continuing this project, you are welcome to implement a > generator for them, probably based on GObject-Introspection. > I am happy to provide directions if you want to pursue such a thing. Therefore, the Qt video sink handling is qt5-only and the corresponding handling for GOBJECT (used for the GStreamer video sink handling) was not taken over for qt6. This presumably means that video playback in Impress presentations does not work when using qt6 with they Qt Wayland plugin, s. tdf#125219 for the corresponding bug for qt5/kf5. (I did not build the qtwayland module to actually test this, though. Video playback with the Qt xcb plugin in a Wayland session works.) [1] https://doc-snapshots.qt.io/qt6-dev/extras-changes-qt6.html [2] https://cgit.freedesktop.org/gstreamer/qt-gstreamer/tree/README Change-Id: Ib105ccfb2c3630ec5d5403793a3cd9ba31d85bdf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122808 Tested-by: Jenkins Reviewed-by: Michael Weghorn <m.weghorn@posteo.de>
2021-09-20use clang-cl's -Zc:dllexportInlines- for clang-cl buildsLuboš Luňák
This is clang-cl's equivalent of -fvisibility-inlines-hidden, and it seems to be also sort of the equivalent of MSVC's -Zc:inline. So it saves build time and disk space. Clang docs say that this is binary compatible in only one direction, so our public C++ code shouldn't be using this, as external C++ code could try to use exported inlines that are no longer there. Change-Id: Ie6217808f8ee4a15344183abfc65038e1558d1b0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122352 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-20use clang-cl's -Zc:dllexportInlines- for Skia (tdf#144598)Luboš Luňák
This is clang-cl's equivalent of -fvisibility-inlines-hidden, and it seems to be also sort of the equivalent of MSVC's -Zc:inline. So it saves build time and disk space. As an additional effect, this disables emitting copies of inlines functions in every .o file where the function is called (even if inlined), which means that it hopefully avoids the problem of SkOpts_avx.cpp generating a copy of SkRect::round() which would include AVX code, and the linker might select this as the instance of SkRect::round() to keep, thus making SSE2 code call AVX code without checking for AVX availability first. Change-Id: I97541ae11d05f489894bc9233271eb21fd520f43 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122335 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-09tdf#130795 use concurrent hashmap in SharedStringPoolNoel Grandin
we are loading a spreadsheet in parallel here, but the parallel threads achievei very little actual concurrency because of heavy contention in the SharedStringPool mutex. So switch to a concurrent hash map. I looked at a couple of different ones (including the Folly one), and this was the one with the simplest resulting code. This takes my load time from 12.5s to 8s Change-Id: I04d6d8e11d613b510eb3bc981f3338819b7ac813 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/121717 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-08-24build Skia with Metal supportLuboš Luňák
Change-Id: I7a9abde4101164af8c47433acfa35f4f9d3b3d04 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120907 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-12make --with-idlc-cpp=cpp work for gcc cpp as a ucpp replacementCaolán McNamara
e.g. the example of https://bugs.launchpad.net/ubuntu/+source/libreoffice/+bug/1524638 has the same output .urd using cpp with these flags as ucpp created Change-Id: Iadfd2deba7d365c66c3260fd6736c031987e107c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120347 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-04Always provision PATH the cygwin way under WindowsThorsten Behrens
With PATH essentially serving the role of LD_LIBRARY_PATH under Windows, there was the notion that this needs to be provided in Windows notation, for win32 gnumake. That was perhaps once true; currently we're always evaluating PATH inside a shell, not the Makefile. So this since a while only worked accidentally, due to cygwin transparently converting between DOS and UNIX PATH vars. It did break though for corner-cases, e.g. SRCDIR!=BUILDDIR, and BUILDDIR e.g. D:\FOO. With that simplification, also GNUMAKE_WIN_NATIVE can go. Change-Id: Ied5a0443dc70e7dc629c0c0620e6ce911d9a73d0 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119941 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-07-26build Skia also on MacLuboš Luňák
This only builds the library, without using it. Change-Id: I54e940bcaa61852b831dbe7ae5660a5daf5fe609 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119356 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-06-01configure: Refactor platform defaultsJan-Marek Glogowski
The main idea was to move complexity from source (and Makefiles) into configure.ac, because otherwise these must replicate the "same" branching, often resulting in diversions. Better to keep the logic in one place (configure.ac) and set additional variables to be used directly by source code and Makefiles. Notably this introduce the "using_*" platform flags, which should be considered constants. There is USING_X11, which actually tells, if the build uses the platform's X11 (and I opted for the removal of HAVE_FEATURE_X11). I also consider variables constant, after they have been exported by AC_SUBST, which should never be conditional, or some AC_DEFINE set them for a config header. A large block of defaults depends on $using_x11, so we set them to the same value, but just if the platform doesn't set it. The other important flag is $using_freetype_fontconfig, if the platform uses freetype and fontconfig. The headless plugin uses cairo for its drawing operations and freetype+fontconfig for text, so $test_cairo = $using_freetype_fontconfig. This is independent from a the cairo canvas! The OpenGL X11 code now depends on USING_X11, but it doesn't yet reflect the filter in Library_vcl.mk protecting glx. I don't know how correct this glx filter is, seeing that the source code just checked for "UNX - some non-X11 targets". Change-Id: Id1ba1a967a5d8d10ee217458be879ed00459f7e6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116440 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-05-29gbuild: implement gb_Library_get_target_for_buildJan-Marek Glogowski
I was wondering why removing instdir stuff forced a rebuild of the cross toolset. Turned out some cross-toolset bits were wrongly depending on host build stuff. It even had FIXME... As a consequence, gb_CPPU_ENV was replaced by config_host.mk flags to provide an CPPU_ENV_FOR_BUILD and also uses the correct OS_FOR_BUILD. Change-Id: I50e8e8dca50ab1ad3164948a585a792a52e4a39a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116359 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-05-26add privacy URL to crashreport dialog & updatecheck tab in optionsChristian Lohmaier
Change-Id: I35cda87c35876469bf581be223bc608e29f07b09 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116105 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-05-10bodge a gtk4 starting point into existenceCaolán McNamara
this is not supposed to work or anything even close to that Change-Id: I46b4fed6a1e6cfc885cb4f7c24660bb6438d5101 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/115293 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-05-05Add --enable-wasm-stripJan-Marek Glogowski
Will just set enable wasm strip for cross-target Change-Id: I0840b843794e4fab694df26608619a7bf06f5e5f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114981 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-05-05WASM: add initial support for Emscripten cross buildJan-Marek Glogowski
- configure with: - --host=wasm64-local-emscripten - had to make a few externals optional, so adding: - --disable-nss - --disable-cmis - --disable-curl Change-Id: I48d1c73d2675ad2e2beaf2c341578199efbd24ee Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111130 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-05-05Switch OPENSSL config var from negative to positiveJan-Marek Glogowski
- align with most of the rest of config_host - rename DISABLE_OPENSSL to ENABLE_OPENSSL - make this configurable Change-Id: Ic3b41fcdda38db66134939f12265e0da24833d60 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/114564 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-04-11Get rid of apache-commons-loggingStephan Bergmann
...using Java 1.4 java.util.logging.Logger instead also for the last remaining uses in reportbuilder. (The mention in swext/mediawiki/src/THIRDPARTYLICENSEREADME.html was presumably a leftover from 4b6ceed4a4a9b152905a8b1712ffb9bd61373c16 "swext: Wiki Publisher does not use those apache-commons libraries".) Change-Id: Ia0bc598fe5844ced11cae497548ec7d09453a99d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113939 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-04-03Add initial support for sccache builds on WNTThorsten Behrens
- gets auto-detected if an sccache binary is in the path - currently external projects using gcc-wrapper are _not_ cached - this needs fixing in the gcc-wrapper - current sccache versions won't work with -Fp (precompiled headers), so while sccache gets called, nothing really is cached. Best build with --enable-pch=no therefore. Change-Id: I78dd7e08ea20ae888236c8c8e8e7a25a405f23b5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/113530 Tested-by: Jenkins Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
2021-03-20tdf#139778 qrcodegen library removal.homeboy445
It was replaced by ZXing library. Change-Id: I49eb809586c7b4ba3a93fd77f804bfc93fead669 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112701 Reviewed-by: René Engelhard <rene@debian.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: Jenkins
2021-03-20tdf#139778 bundle external:zxing libhomeboy445
Change-Id: I0023f6ce8315427b1a3deaf755e78ae06475b08c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112053 Reviewed-by: René Engelhard <rene@debian.org> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com> Tested-by: René Engelhard <rene@debian.org> Tested-by: Jenkins
2021-02-28Upgrade fuzzers to LIB_FUZZING_ENGINEAndrzej Hunt
And check that LIB_FUZZING_ENGINE is set during configure. Because: 1. It's easier to build locally this way (you don't need to build or hack a libFuzzingEngine.a - instead you can just specify LIB_FUZZING_ENGINE=-fsanitize=fuzzer to produce a valid build). 2. Using -lFuzzingEngine is deprecated [1] for various reasons [2]. The old behaviour can be emulated if desired by setting LIB_FUZZING_ENGINE=-lFuzzingEngine . This patch was tested as follows: - Building LO within oss-fuzz via: python infra/helper.py build_fuzzers --sanitizer address libreoffice </path/to/patched-libreoffice-core> python infra/helper.py check_build libreoffice - Building LO fuzzers standalone via: export CC="clang-11" export CXX="clang++-11 -stdlib=libc++" export CFLAGS="-fsanitize=address -fsanitize-address-use-after-scope -fsanitize=fuzzer-no-link -DFUZZING_BUILD_MODE_UNSAFE_FOR_PRODUCTION" export CXXFLAGS="$CFLAGS -stdlib=libc++" export LDFLAGS="$CFLAGS -Wl,--compress-debug-sections,zlib -lpthread" export LIB_FUZZING_ENGINE=-fsanitize=fuzzer ./autogen.sh --with-distro=LibreOfficeOssFuzz --with-system-libxml make fuzzers (--with-system-libxml only appears to be needed because of issues specific to my build environment/Suse 15.2. I'm invoking clang-11 simply because that's the most modern clang I have installed, plain clang should also work on most sufficiently modern systems). [1] https://github.com/google/oss-fuzz/blob/481280c65048fd12fb2141b9225af511a9ef7ed2/infra/presubmit.py#L46 [2] https://github.com/google/oss-fuzz/issues/2164 Change-Id: Iddb577c30a39620e72372ef6c2d3fda67f8aabdf Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111691 Tested-by: Jenkins Tested-by: Caolán McNamara <caolanm@redhat.com> Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-02-17More targeted suppression of bogus GCC -Werror=stringop-overflow=Stephan Bergmann
...given that <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87296#c5> "[8/9/10/11 Regression] -Wstringop-overflow false positive due to using MEM_REF type of &MEM" is declared fixed now on GCC 11 trunk. (Moving -Wno-stringop-overflow from gb_CFLAGS_WERROR to gb_CXXFLAGS_COMMON is done for no other reason than to harmonize this with the code for the similar HAVE_BROKEN_GCC_WMAYBE_UNINITIALIZED.) Change-Id: I3468138c9bbda28f754d4162cb9c059796bd3932 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/111029 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-12-25Remove vlc part since experimental since 5 yearsJulien Nabet
However considering git history about vlc part (see https://cgit.freedesktop.org/libreoffice/core/log/?qt=grep&q=vlc) it seems there's no real patch since 2013 + it's been explicitely indicated as experimental since 2015 See http://document-foundation-mail-archive.969070.n3.nabble.com/About-vcl-status-in-avmedia-keep-or-removed-unmaintained-code-since-7-years-tt4293282.html Of course if someone wants to keep on the work on it, it's always possible to revert the patch. Change-Id: Ia1602ea61b7ffa577148a80f974ebdcb71495fbb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108283 Tested-by: Jenkins Reviewed-by: Julien Nabet <serval2412@yahoo.fr>
2020-12-21Retire the bit-rotting LibreOfficeLight iOS appTor Lillqvist
Change-Id: I21b8055fc97d8dfb8429e7dafa1a3982c3b7499b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/108122 Tested-by: Tor Lillqvist <tml@collabora.com> Reviewed-by: Tor Lillqvist <tml@collabora.com>
2020-12-03Replace unowinreg.dll with execution of `reg QUERY`Stephan Bergmann
The SDK's <https://wiki.openoffice.org/wiki/Documentation/DevGuide/ProUNO/Java/ Transparent_Use_of_Office_UNO_Components> on all platforms included the Windows- specific unowinreg.dll in generated jars (so that those jars, when distributed to a Windows environment, would find a LO installation by inspecting the Windows registry). That unowinreg.dll was originally built as a 32-bit DLL (though when building a 64-bit Windows LO, it happened to be built as a 64-bit DLL). For non-Windows LO builds, it could either be built locally with a MinGW toolchain (--enable-build-unowinreg) or downloaded from dev-www.libreoffice.org. However, that had various issues: For one, unowinreg.dll was not necessarily available in a distributed jar as a 64-bit DLL for use with a 64-bit JRE on Windows. (Theoretically, running such a jar with a 32-bit JRE to access a 64-bit LO installation's URE jars could have worked. But practically, those URE jars in turn require native DLLs, which would then not have been available as 32-bit DLLs for use in the 32-bit JRE.) For another, at least the unowinreg.dll resulting from --enable-build-unowinreg on Fedora 33 would have had a dependency on libgcc_s_dw2-1.dll that would generally not have been available in a target Windows environment. There appears to be no pure Java way to read the Windows registry, but instead of using a native code DLL for that, it appears to work just as well to call out to reg.exe and parse its output. This removes the --enable-build-unowinreg and --with-mingw-cross-compiler configuration options. (The sole use of the MinGW toolchain in LO was for building unowinreg.dll.) Change-Id: I3283ea38c884d3221a205e5ab6ec99a2691ef474 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/107140 Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> Reviewed-by: Stephan Bergmann <sbergman@redhat.com> Tested-by: Jenkins
2020-11-21firebird: build fixes (incl. parallel build)Jan-Marek Glogowski
The main idea is to get rid of the "unset MAKEFLAGS". AFAI can see, the whole CPU stuff isn't used anymore. So we can drop the whole FB_CPU_ARG handling. Since LO doesn't use any of make's implicit rules, the build breaks, but luckily it just requires a single rule for the btyacc build - just a Firebuild build tool. Then there is the whole broken handling of LIBTOMMATH and LIBATOMIC_OPS already in LO's configure.ac. I don't know if any internal build of Firebird with these as system libs would work. I guess people either have a system Firebird or also build with internal libtommath and libatomic_ops. This fixes just the obvious errors. I didn't try to build it, so there might still be typos (TBH I thought hard about just dropping the system build of these libraries, after seeing the broken configure.ac). And I'm not sure our / the system boost preprocessor library is ever used over the Firebird-internal copy. It also looks like it's also just used in an other build tool and nothing of the Firebird DB itself depends on it. Then there is the movement of the install_name_tool / otool patching on MacOS from the patch into the ExternalProject to further shrink the patches, as the build doesn't depend on it. This also introduces a different debug build mode for the gcc-/g++-wrapper: MSVC_USE_INDIVIDUAL_PDBS. It uses -Fd to write a separate PDB per output file instead of using -FS to use sync writes to a single PDB, which might work around the PDB access failures seen by Jenkins for linking executables. In theory it's also faster and should work with all the other wrapper users, but I don't want to open that can of additional build errors (yet), for eventually marginal gains. Change-Id: I8d4c5d2f17def9e840a67ef1004787e8baaffa83 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/105902 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
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-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>
generated by cgit (git 2.34.1) at 2025-03-06 13:06:04 +0000