summaryrefslogtreecommitdiff
path: root/solenv/gbuild
AgeCommit message (Collapse)Author
2021-11-04Fix check for libstdc++Stephan Bergmann
...now that we have HAVE_LIBSTDCPP since 7158acde7756a264c09e24e1cfe4c81db700b920 "Consolidate -D_GLIBCXX_DEBUG for --enable-dbgutil builds against libstdc++". HAVE_LIBCXX was only ever defined in config_host/config_libcxx.h (since 90d2155912bcee40377620d4836726041a72d537 "Work around latest Boost 1.65.1 still using deprecated std::auto_ptr"), never as a makefile variable, so this check (introduced in b1141fa61073b3f24e1a3574afa55a954e5a153d "Cut down on -pthread/-lpthread proliferation") always succeeded, whether libstdc++ or not. Change-Id: If71615b0ae2c6d3765eb538857f36bb1d23a667a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124683 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-04Resolves: tdf#97046 ensure build system variables start with gb_Sabyasachi Bhoi
Change the variable name: var2file to gb_var2file Change-Id: Ib7d64b76cfe10e6c2df1a176674a360b28704070 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124666 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
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-11-01remove unused gb_CObject__command_pattern parameterLuboš Luňák
Usage removed in bc39f6b0e62b0a54500bf3986f971a43fe8f843d . Change-Id: Ie2d8782f84ae39360698885d238ec2154a5b0d82 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124533 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-31fix usage of MSVC's -debug:fastlinkLuboš Luňák
Using /link while only compiling does nothing (and MSVC apparently doesn't bother to warn). Fix gbuild to pass -debug:fastlink when linking, and limit it to dbgutil builds, since pdb files cannot be moved elsewhere if the option is used. Change-Id: I0325c55ddea1ce881b60b1373c81019d154ef672 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124526 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-28Fix passing DYLD_LIBRARY_PATH into lldb on macOSStephan Bergmann
...making sure that the shell expands the leading DYLD_LIBRARY_PATH=${DYLD_LIBRARY_PATH:+$DYLD_LIBRARY_PATH:}... before it reaches lldb. (This gets rid of gb_{Cppunit,Pyhton}_{PRE,POST}GDBTRACE again. No idea why c38a4d9ce248b4b3fcc9208b25dfa599fe506ac0 "Make the CPPUNITTRACE="lldb --" thing work again (on macOS)" used -s with a temp file rather than -o to pass that env var into lldb.) Change-Id: I9ae5217a9629981c8652fc5aca8f97fa6eb99729 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124331 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-10-28-flto: only use firstword of PARALLELISMChristian Lohmaier
jenkins agents use PARALLELISM with additional load limit, e.g. PARALLELISM="16 -l 24" causing the linker to complain about not finding -l24 when lto is enabled. So only use the first element/the number of jobs to use and omit the load limit here. Change-Id: Ie3e2bdbde1b89d9371d1d9b9e426f42a91d2eca8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124288 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com>
2021-10-28move a comment to the proper placeLuboš Luňák
Change-Id: I8d8b921febd0b57213bbb912a600e0c7698da555
2021-10-25bsd (as used by macOS) ar does not support '@' optionCaolán McNamara
so gb_LinkTarget__command_staticlink should use the same workaround for that as gb_LinkTarget__command_dynamiclink does Change-Id: Ied9d8a3b99f09d6ea1b705e0c1ce3ef3b2d14190 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/124156 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-10-14filter out also link.exe messages about LTO code generationLuboš Luňák
Change-Id: I4f61bfd829429745141cd03eb0db625fe0458e32 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123584 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-13use -flto=auto for gcc if no $PARALLELISM is setLuboš Luňák
I'm not sure if all gcc versions support the value, but if older ones do not they at least silently accept it. Change-Id: If18ce1cbf6122cf9ded00eee5c2058d70e486c0c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123540 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-13MSVC LTO does not like mixing 32bit and 64 codeLuboš Luňák
So disable LTO for x64 code when building for 32bit. Change-Id: I8445d8307b3b797b78cea12e6322e0d792c71dfd Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123537 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-11clang does not support -flto=<number>Luboš Luňák
This may happen when building with GCC when Clang is used for Skia and --with-parallelism is in effect. Change-Id: Ic52dbbcf53253ed73413af4ea8254b000eee72d6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123430 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-11merge LD_PLUGIN use with other LTO useLuboš Luňák
It seems LD_PLUGIN predates the other --plugin usage, so make that one use LD_PLUGIN instead of using --plugin twice. Change-Id: I00133be18e576bc9a797853621a20dd7d5245344 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123257 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-11use ThinLTO for Clang everywhereLuboš Luňák
No idea why it should be used only on Apple platforms and normal LTO elsewhere. ThinLTO should build faster and the result should perform roughly the same. Change-Id: Ie93cf0ba810ee5bb2309fcbd3548a4847587b3d4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123256 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-10-07remove python make dependency from MoTargetCaolán McNamara
not needed since... commit 7fdf1663ed8e689e7fb154ab22a9dcb7fc7bf43c Author: Caolán McNamara <caolanm@redhat.com> Date: Thu Sep 14 15:57:38 2017 +0100 remove interim update module for gettext support Change-Id: I05df619848cde842a5cda79d20e013914ce882d4 Change-Id: I094c033db356f32b93c77f7bdbd4ce5be8b0b0ae Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123151 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-10-03unterminated call to function 'call': missing ')'.Caolán McNamara
Change-Id: Ida812eb3a002da3d99ddf3179d674a653f7ed2b9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123027 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-10-03TODO: remove missing .po support when writerfilter .po files existCaolán McNamara
Change-Id: I8f20845fcb1fbd598cf1c1c8c8ff20b3e9c37bfc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/123012 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.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-23Look for the udkapi types.rdb file in the right place when cross-compilingTor Lillqvist
Fixes cross-compilation to iOS on macOS. Previously is was looking for instdir_for_build/LibreOfficeDev.app/Contents/program/types.rdb The correct location is instdir_for_build/LibreOfficeDev.app/Contents/Resources/ure/share/misc/types.rdb Now it is possible to build the master branch for iOS again. (No idea whether it works.) Change-Id: If5b09c77601b5a5136c26e1d383654a85b6cc795 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122516 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-09-22avoid some more D9025 warningsLuboš Luňák
Change-Id: I01f8df5f399b17f46da9a59501bea28bc70cac4e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122431 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-22Apparently we need to define gb_Library_PLAINEXT_FOR_BUILD for iOSTor Lillqvist
Helps a build for iOS proceed a bit further. Change-Id: Icb0465eb204effbc0b777b5066d40d9938924eed Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122421 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com>
2021-09-22make .pch file also depend on its source .hxx fileLuboš Luňák
This dependency is normally handled by either the .pch not existing (and so it needs building), or GCC/Clang output it in the deps, but MSVC doesn't seem to provide this dependency, so modifying the .hxx there doesn't trigger a rebuild. Change-Id: I83415d97b98b8861b3d53cba07c4ac2748e9f476 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122413 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-20use MSVC's /Zc:inline option to reduce binary sizeLuboš Luňák
If I'm getting it right, MSVC has a non-conforming feature that allows to declare a function as inline without defining its body in the header, and it'll work if the function is actually emitted elsewhere, and the linker will sort it out. This seems to be implemented by forcing emitting of out-of-line copies of all inline functions, which is wasteful. /Zc:inline disables this useless feature, which seems to save quite some space (optimized build, starmath's .o files 350k->220k, smlo.dll 2.5M->2.2M). The docs don't say anything about binary compatibility, but treat it the same way as -Zc:dllexportInlines, just in case. This change also may help avoid the tdf#144598 problem for our AVX/etc. code, such as in Calc. Change-Id: I73cc5d46ba1e4245e8d3b6688804c2b9684d2f9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122334 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
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-19make "-external/" valid gbuild exclusion for FORCE_COMPILELuboš Luňák
Get the name of the directory extra level up, which is 'external' for external modules, and check that too. Change-Id: Ie9a3bffea0c64c07cf2e9dfa221fd27106a05443 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122307 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-18make FORCE_COMPILE_ALL more flexible than all or nothingLuboš Luňák
Rename it to FORCE_COMPILE and it takes the --enable-symbols specification of what to include, for example FORCE_COMPILE="all -sw/ -Library_sc". Change-Id: I92afd8e0abc75d3566285c197d6640c26c03db36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122248 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-18make COMPILER_EXTERNAL_TOOL=1 work properly with generated sourcesLuboš Luňák
The normal compile commands would fail if the tool standing in as the compiler would not generate e.g. the dependency files. Change-Id: I590a925d3562c9677cbd836095cd0b8cfeb9613b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122247 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-18don't force compiler plugins when COMPILER_EXTERNAL_TOOL=1 is usedLuboš Luňák
Change-Id: I741d4e5450ba66d4452ee2e5398eaac0643a371f Reviewed-on: https://gerrit.libreoffice.org/c/core/+/122246 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-09-11add -DSYSTEM_NSS to flags ignored for system PCHLuboš Luňák
Change-Id: I4afdf324956b0280ceeaf2d18174dedbb091b5b0
2021-08-23fix ObjC/C++ generated sources linking on MacLuboš Luňák
Change-Id: I4d4a2abdf762e5442d89ce9b6475753e1f43f314 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120802 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-08-22Give gengal invocations their own UserInstallationsStephan Bergmann
Building e.g. Gallery_backgrounds tries to access a UserInstallation at various places, first at > #0 0x00007ffff29b0302 in EmbeddedFontsHelper::clearTemporaryFontFiles() () at vcl/source/gdi/embeddedfontshelper.cxx:60 > #1 0x00007ffff2dd6bb4 in InitVCL() () at vcl/source/app/svmain.cxx:304 > #2 0x00007ffff2dd66b6 in ImplSVMain() () at vcl/source/app/svmain.cxx:190 > #3 0x00007ffff2dd6898 in SVMain() () at vcl/source/app/svmain.cxx:231 > #4 0x000000000041215d in sal_main() () at vcl/source/salmain/salmain.cxx:34 It would either access the real UserInstallation (if the bootstrap ini-file has already been delivered to instdir) or try to access some (typically non- existent) /user. That appears to be generally harmless, but to be on the safe side, pass the gengal invocation an explicit UserInstallation in workdir (which does not exist, and does not get populated, but just prevents accidentally accessing a real UserInstallation). Change-Id: Idc709a4bd44ce0dddbafaac25141215730808fca Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120838 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-22gengal needs Library_localedata_en nowStephan Bergmann
Whatever caused that requirement, but a from-scratch build of e.g. Gallery_backgrounds failed for me (with a follow-on SIGABRT after "framework/source/services/desktop.cxx:176: Desktop::~Desktop(): Who forgot to dispose this service?") because it failed to load instdir/program/../program/liblocaledata_en.so at > #1 0x00007fffda0b9671 in i18npool::LocaleDataImpl::getFunctionSymbol(com::sun::star::lang::Locale const&, char const*) (this=0x159b630, rLocale=..., pFunction=0x7fffda136ed8 "getAllFormats0") at i18npool/source/localedata/localedata.cxx:1460 > #2 0x00007fffda0b6a93 in i18npool::LocaleDataImpl::FormatSection::getFunc(i18npool::LocaleDataImpl&, com::sun::star::lang::Locale const&, char const*) (this=0x7fffffffc840, rLocaleData=..., rL=..., pName=0x7fffda136ed8 "getAllFormats0") at i18npool/source/localedata/localedata.cxx:857 > #3 0x00007fffda0b6b5c in i18npool::LocaleDataImpl::getAllFormats(com::sun::star::lang::Locale const&) (this=0x159b630, rLocale=...) at i18npool/source/localedata/localedata.cxx:865 > #4 0x00007fffda0d4815 in NumberFormatCodeMapper::getFormats(com::sun::star::lang::Locale const&) (this=0x1594fa0, rLocale=...) at i18npool/source/numberformatcode/numberformatcode.cxx:150 > #5 0x00007fffda0d4155 in NumberFormatCodeMapper::getAllFormatCode(short, com::sun::star::lang::Locale const&) (this=0x1594fa0, formatUsage=8, rLocale=...) at i18npool/source/numberformatcode/numberformatcode.cxx:92 > #6 0x00007ffff572a824 in LocaleDataWrapper::loadCurrencyFormats() (this=0x159b3f0) at unotools/source/i18n/localedatawrapper.cxx:544 > #7 0x00007ffff572777e in LocaleDataWrapper::loadData() (this=0x159b3f0) at unotools/source/i18n/localedatawrapper.cxx:131 > #8 0x00007ffff57271b4 in LocaleDataWrapper::LocaleDataWrapper(LanguageTag const&, std::__debug::vector<rtl::OUString, std::allocator<rtl::OUString> > const&) (this=0x159b3f0, rLanguageTag=..., rOverrideDateAcceptancePatterns=std::__debug::vector of length 0, capacity 0) at unotools/source/i18n/localedatawrapper.cxx:80 > #9 0x00007ffff5766fd6 in SvtSysLocale_Impl::SvtSysLocale_Impl() (this=0x158a4e0) at unotools/source/misc/syslocale.cxx:67 > #10 0x00007ffff5768ad7 in std::construct_at<SvtSysLocale_Impl>(SvtSysLocale_Impl*) (__location=0x158a4e0) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/stl_construct.h:97 > #11 0x00007ffff5768b1c in std::allocator_traits<std::allocator<SvtSysLocale_Impl> >::construct<SvtSysLocale_Impl>(std::allocator<SvtSysLocale_Impl>&, SvtSysLocale_Impl*) (__a=..., __p=0x158a4e0) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/alloc_traits.h:514 > #12 0x00007ffff57688c2 in std::_Sp_counted_ptr_inplace<SvtSysLocale_Impl, std::allocator<SvtSysLocale_Impl>, (__gnu_cxx::_Lock_policy)2>::_Sp_counted_ptr_inplace<>(std::allocator<SvtSysLocale_Impl>) (this=0x158a4d0, __a=...) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/shared_ptr_base.h:519 > #13 0x00007ffff576860a in std::__shared_count<(__gnu_cxx::_Lock_policy)2>::__shared_count<SvtSysLocale_Impl, std::allocator<SvtSysLocale_Impl>>(SvtSysLocale_Impl*&, std::_Sp_alloc_shared_tag<std::allocator<SvtSysLocale_Impl> >) (this=0x7fffffffd0a8, __p=@0x7fffffffd0a0: 0x0, __a=...) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/shared_ptr_base.h:650 > #14 0x00007ffff57684c6 in std::__shared_ptr<SvtSysLocale_Impl, (__gnu_cxx::_Lock_policy)2>::__shared_ptr<std::allocator<SvtSysLocale_Impl>>(std::_Sp_alloc_shared_tag<std::allocator<SvtSysLocale_Impl> >) (this=0x7fffffffd0a0, __tag=...) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/shared_ptr_base.h:1342 > #15 0x00007ffff576838d in std::shared_ptr<SvtSysLocale_Impl>::shared_ptr<std::allocator<SvtSysLocale_Impl>>(std::_Sp_alloc_shared_tag<std::allocator<SvtSysLocale_Impl> >) (this=0x7fffffffd0a0, __tag=...) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/shared_ptr.h:409 > #16 0x00007ffff5768164 in std::allocate_shared<SvtSysLocale_Impl, std::allocator<SvtSysLocale_Impl>>(std::allocator<SvtSysLocale_Impl> const&) (__a=...) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/shared_ptr.h:863 > #17 0x00007ffff5767dfc in std::make_shared<SvtSysLocale_Impl>() () at ~/gcc/trunk/inst/include/c++/12.0.0/bits/shared_ptr.h:879 > #18 0x00007ffff5767583 in SvtSysLocale::SvtSysLocale() (this=0x7fffffffd120) at unotools/source/misc/syslocale.cxx:122 > #19 0x00007ffff015148f in FwkResId(TranslateId) (aId=...) at framework/source/fwe/classes/fwkresid.cxx:22 > #20 0x00007ffff025f333 in framework::Desktop::constructorInit() (this=0x1588850) at framework/source/services/desktop.cxx:106 > #21 0x00007ffff0265c1c in (anonymous namespace)::createDesktop(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) (context=...) at framework/source/services/desktop.cxx:1764 > #22 0x00007ffff0265ce5 in framework::getDesktop(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) (context=...) at framework/source/services/desktop.cxx:1773 > #23 0x00007ffff0265d9e in com_sun_star_comp_framework_Desktop_get_implementation(com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (context=0x522200) at framework/source/services/desktop.cxx:1782 > #24 0x00007ffff5a5d864 in std::__invoke_impl<com::sun::star::uno::XInterface*, com::sun::star::uno::XInterface* (*&)(com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&), com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&>(std::__invoke_other, com::sun::star::uno::XInterface* (*&)(com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&), com::sun::star::uno::XComponentContext*&&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (__f=@0x54bb58: 0x7ffff0265d5f <com_sun_star_comp_framework_Desktop_get_implementation(com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&)>) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/invoke.h:61 > #25 0x00007ffff5a551f4 in std::__invoke_r<com::sun::star::uno::XInterface*, com::sun::star::uno::XInterface* (*&)(com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&), com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&>(com::sun::star::uno::XInterface* (*&)(com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&), com::sun::star::uno::XComponentContext*&&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (__fn=@0x54bb58: 0x7ffff0265d5f <com_sun_star_comp_framework_Desktop_get_implementation(com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&)>) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/invoke.h:114 > #26 0x00007ffff5a4d254 in std::_Function_handler<com::sun::star::uno::XInterface* (com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&), com::sun::star::uno::XInterface* (*)(com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&)>::_M_invoke(std::_Any_data const&, com::sun::star::uno::XComponentContext*&&, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) (__functor=..., __args#0=@0x7fffffffd4f0: 0x522200, __args#1=...) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/std_function.h:291 > #27 0x00007ffff5a3f913 in std::function<com::sun::star::uno::XInterface* (com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&)>::operator()(com::sun::star::uno::XComponentContext*, com::sun::star::uno::Sequence<com::sun::star::uno::Any> const&) const (this=0x54bb58, __args#0=0x522200, __args#1=...) at ~/gcc/trunk/inst/include/c++/12.0.0/bits/std_function.h:568 > #28 0x00007ffff5a2a396 in cppuhelper::ServiceManager::Data::Implementation::doCreateInstance(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) (this=0x54baa0, context=...) at cppuhelper/source/servicemanager.cxx:704 > #29 0x00007ffff5a2a12a in cppuhelper::ServiceManager::Data::Implementation::createInstance(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&, bool) (this=0x54baa0, context=..., singletonRequest=false) at cppuhelper/source/servicemanager.cxx:672 > #30 0x00007ffff5a2d02d in cppuhelper::ServiceManager::createInstanceWithContext(rtl::OUString const&, com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) (this=0x523450, aServiceSpecifier=..., Context=...) at cppuhelper/source/servicemanager.cxx:1003 > #31 0x00007ffff6cd9922 in com::sun::star::frame::Desktop::create(com::sun::star::uno::Reference<com::sun::star::uno::XComponentContext> const&) (the_context=...) at workdir/UnoApiHeadersTarget/offapi/normal/com/sun/star/frame/Desktop.hpp:38 > #32 0x00007ffff6cd8c07 in SfxApplication::Initialize_Impl() (this=0x1588150) at sfx2/source/appl/appinit.cxx:182 > #33 0x00007ffff6cb776a in SfxApplication::GetOrCreate() () at sfx2/source/appl/app.cxx:122 > #34 0x0000000000405ecf in (anonymous namespace)::GalApp::Main() (this=0x4204e0 <vclmain::createApplication()::aGalApp>) at svx/source/gengal/gengal.cxx:254 > #35 0x00007ffff2dd6777 in ImplSVMain() () at vcl/source/app/svmain.cxx:199 > #36 0x00007ffff2dd6898 in SVMain() () at vcl/source/app/svmain.cxx:231 > #37 0x0000000000410f1f in sal_main() () at vcl/source/salmain/salmain.cxx:34 > #38 0x0000000000410efa in main(int, char**) (argc=10, argv=0x7fffffffded8) at vcl/source/salmain/salmain.cxx:29 This fix should remove the need for the cross-build--only fix 0e142fa01972ad28182ca54b855d0ecae0d5c83b "cross-toolset: gengal now needs localedata_en", which it reverts. Change-Id: If71b7249c19619a83911c7624e3d99077decba31 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120837 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2021-08-10for DISABLE_DYNLOADING support linking to static .a system libsCaolán McNamara
Change-Id: I0b7e07c93f7314506c5b99847b53c09f4fc6d31c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120261 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-09remove unneeded -ldl for DISABLE_DYNLOADINGCaolán McNamara
I think we only had -ldl in here for -lpthread which is gone now Change-Id: I8a52a5cd4aeae8aff793c98b7f55d7a73e068b9a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/120196 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com>
2021-08-05Avoid ODR violation, consistently define ZLIB_CONSTStephan Bergmann
At least my --enable-lto --enable-mergelibs build diagnosed > [build LNK] Library/libmergedlo.so > workdir/UnpackedTarball/zlib/zlib.h:86:16: warning: type ‘struct z_stream_s’ violates the C++ One Definition Rule [-Wodr] > 86 | typedef struct z_stream_s { > | ^ > workdir/UnpackedTarball/zlib/zlib.h:86: note: a different type is defined in another translation unit > 86 | typedef struct z_stream_s { > | > workdir/UnpackedTarball/zlib/zlib.h:87:20: note: the first difference of corresponding definitions is field ‘next_in’ > 87 | z_const Bytef *next_in; /* next input byte */ > | ^ > workdir/UnpackedTarball/zlib/zlib.h:87: note: a field of same name but different type is defined in another translation unit > 87 | z_const Bytef *next_in; /* next input byte */ > | (And ZLIB_CONST then required a small adaption in tools/source/zcodec/zcodec.cxx, plus some loplugin:redundantcast. And gb_PrecompiledHeader_ignore_flags_system had to be updated to avoid errors like > Error reusing pch/inc/pch/precompiled_system by Library_wpftdraw. > precompiled header flags : -DBOOST_ALL_NO_LIB -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_MEM_FN_ENABLE_CDECL -DBOOST_OPTIONAL_USE_OLD_DEFINITION_OF_NONE -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=msci -DDBG_UTIL -DEXCEPTIONS_ON -DINTEL -DNOMINMAX -DOSL_DEBUG_LEVEL=1 -DPCH_LEVEL=4 -DSAL_LOG_INFO -DSAL_LOG_WARN -DWIN32 -DWNT -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -D_CRT_SECURE_NO_DEPRECATE -D_DEBUG -D_DLL -D_HAS_AUTO_PTR_ETC -D_MT -D_REENTRANT -D_SCL_SECURE_NO_WARNINGS -D_SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING -D_SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING -D_SILENCE_CXX17_RESULT_OF_DEPRECATION_WARNING -D_WIN32_WINNT=0x0601 -D_X86_=1 -EHs -GR -GS -Gd -Gs -Gy -MDd -Od -W4 -Wv:18 -Zc:__cplusplus -Zm500 -bigobj -nologo -permissive- -std:c++17 -utf-8 -wd4127 -wd4201 -wd4244 -wd4250 -wd4251 -wd4267 -wd4275 -wd4505 -wd4611 -wd4706 > object flags : -DBOOST_ALL_NO_LIB -DBOOST_ERROR_CODE_HEADER_ONLY -DBOOST_MEM_FN_ENABLE_CDECL -DBOOST_OPTIONAL_USE_OLD_DEFINITION_OF_NONE -DBOOST_SYSTEM_NO_DEPRECATED -DCPPU_ENV=msci -DDBG_UTIL -DEXCEPTIONS_ON -DINTEL -DNOMINMAX -DOSL_DEBUG_LEVEL=1 -DPCH_LEVEL=4 -DSAL_LOG_INFO -DSAL_LOG_WARN -DWIN32 -DWNT -DZLIB_CONST -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NON_CONFORMING_SWPRINTFS -D_CRT_SECURE_NO_DEPRECATE -D_DEBUG -D_DLL -D_HAS_AUTO_PTR_ETC -D_MT -D_REENTRANT -D_SCL_SECURE_NO_WARNINGS -D_SILENCE_CXX17_CODECVT_HEADER_DEPRECATION_WARNING -D_SILENCE_CXX17_OLD_ALLOCATOR_MEMBERS_DEPRECATION_WARNING -D_SILENCE_CXX17_RESULT_OF_DEPRECATION_WARNING -D_WIN32_WINNT=0x0601 -D_X86_=1 -EHs -GR -GS -Gd -Gs -Gy -MDd -Od -W4 -Wv:18 -Zc:__cplusplus -Zm500 -bigobj -nologo -permissive- -std:c++17 -utf-8 -wd4127 -wd4201 -wd4244 -wd4250 -wd4251 -wd4267 -wd4275 -wd4505 -wd4611 -wd4706 > reason : -DZLIB_CONST -DZLIB_CONST > Incorrect precompiled header setup or internal gbuild error. > make[1]: *** [C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/writerperfect/Library_wpftdraw.mk:31: C:/cygwin/home/tdf/jenkins/workspace/gerrit_windows/workdir/PrecompiledHeader/nodebug/Timestamps/Library_wpftdraw_reuse] Error 1 with --enable-pch.) Change-Id: Iadd3c90a65993ebef98190458762b1c86d425c4d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119961 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@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-26add gbuild support for ObjC/C++ sources from tarballsLuboš Luňák
Change-Id: I49632bf9dedf9603449fb5bc9e6a819586258b05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119355 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de>
2021-07-23workaround for apple clang sometimes not generating PCHCollabora
Change-Id: I50a215e0cf3bf7f6f6d6dc86cf89355e2de19c11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/119009 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-07-12enable -Wshadow on clangNoel Grandin
which is on for gcc, but doesn't seem to be on for clang Change-Id: If71e03511e093280db55426fd4c1d076f760b5a9 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118768 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2021-06-28Allow headless make debugrunJan-Marek Glogowski
I have not the slightest idea, why I added this code in commit 6cdfe5ebb4f6c06bfa8b0e67e778dd68131c14e3 ("Drop some headless mode variants"). This prevents running "make debugrun" headless using SAL_USE_VCLPLUGIN=svp. A HEADLESS variable is just referred in some make targets, but the environment doesn't affect them. So just remove that code. Change-Id: Icdf76bea6c75c7b14c3f01287ceb0fd4a11cb2d5 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/118019 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-06-24cross-toolset: fix real cross help buildingJan-Marek Glogowski
Regression from commit 14069d84174ca7a4e60db4d75912903e9679b643 ("configure: Improve help-options handling"). We now must forward the help and extension configure options, as this is needed by the cross toolset to know, if it needs to build the HelpIndexer and HelpLinker executables. Also get rid of gb_Helper_optional_for_host. While it's in theory more correct, it makes gb_Helper_optional more complex, so we now rely on the fact, that the config_build.mk BUILD_TYPE is a subset of the config_host.mk BUILD_TYPE. This should fix the Windows Arm64 build, which currently seem to be the only cross-build including help. Change-Id: I8b90923c891b43cd2655b2578015c9bd579aae7d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/117758 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-06-22configure: Improve help-options handlingJan-Marek Glogowski
This patch includes: * A README.help.md as a general documentation for the different help types, the LO code and help-related build options. * Adds --disable-xmlhelp for removing the xmlhelp support from the build. Disable for iOS, Android and Emscripten. This was partly included in HAVE_FEATURE_DESKTOP before. * Rename WITH_HELP define to WITH_HELPPACKS, which reflects the actual usage AFAIK. * Depend --with-omindex on --with-help=online and don't override the --with-help setting. Error out on conflicting options. * Depend --with-helppack-integration on build help variants, which actually result in help packs. Kind of reverts commit 2c38ea6d16b910294220cefaf8ae6a0683e6405a ("Building without --with-help is not supposed to disable help functionality"). Change-Id: Ie4cb73905b3ed94e991d9f1bd75cfbd6de9da385 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116222 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-06-08Unset TZ when starting UITests on WindowsMike Kaganski
This workarounds a problem that some tests in trackedChanges.py fail on Windows in specific time spans, at least in Europe/Moscow time zone: the change date in the dialog is reported according to local system time, while the expected date string is created in Python wrong, likely because datetime.datetime.now in the native Windows Python takes into account both system timezone data and the TZ environment variable coming from Cygwin (or some other kind of Python bug). The time reported by datetime.datetime.now was off by -2 hours, and resulting date string was wrong from 00:00 till 02:00. See upstream bug at https://bugs.python.org/issue44352. Change-Id: Ife3bcf000acac37f624a1065512513cc41dae596 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116862 Tested-by: Mike Kaganski <mike.kaganski@collabora.com> Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-05-31Enable -bigobj on MSVCMike Kaganski
This fixes this error: C:\lo\src\core\sc\qa\unit\ucalc_copypaste.cxx : fatal error C1128: number of sections exceeded object file format limit: compile with /bigobj According to [1], it is enabled by default in all UWP projects, which presumably means there's no harm in enabling it (other than some compiling overhead, which impact is unclear at the moment). Enabling it unconditionally, it would not create a mismatch like in 7788e87ce25183c1d6f92a3b972b8dd8c88e58e3. [1] https://docs.microsoft.com/en-us/cpp/build/reference/bigobj-increase-number-of-sections-in-dot-obj-file Change-Id: Id176add21fec2a6084149e9ff23bdafb10b3d579 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116454 Tested-by: Jenkins Reviewed-by: Mike Kaganski <mike.kaganski@collabora.com>
2021-05-31gbuild: implement gb_UnoApi_get_target_for_buildJan-Marek Glogowski
Change-Id: Iaee243510023bf935097914fd6c4fcb701d35c13 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116438 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>
generated by cgit (git 2.34.1) at 2025-01-16 07:13:44 +0000