summaryrefslogtreecommitdiff
path: root/compilerplugins/clang/finalclasses.py
AgeCommit message (Expand)Author
2021-06-19loplugin:finalclassesNoel Grandin
2021-03-16systools is no longer part of the URE interfaceStephan Bergmann
2020-11-13improve sorting in global-analysis pluginsNoel
2020-07-13Don't rely on Python's treatment of unrecognized escape sequencesMike Kaganski
2020-04-03loplugin:finalclasses in xmlsecurity..UnoControlsNoel Grandin
2019-12-22loplugin:finalclasses in xmlsecurityNoel Grandin
2019-12-12Fix typoAndrea Gelmini
2019-12-12loplugin:finalclassesNoel Grandin
2018-07-12loplugin:mergeclasses fix ignoring some stuffNoel Grandin
2018-04-10put the loplugin output files in the workdirNoel Grandin
2017-10-17loplugin:finalclasses trim the output a littleNoel Grandin
2017-10-03new loplugin:finalclassesNoel Grandin
generated by cgit (git 2.34.1) at 2024-07-06 15:30:24 +0000
ndefined 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-26Use && rather than ; between commands, to not hide errorsStephan Bergmann Change-Id: I4f8dc3d338b64452dc92c850c7dc174bb59611bb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/162592 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@allotropia.de> 2023-09-18JavaScript uno bindings for WASM with Embind - first cutSarper Akdemir A rough implementation of uno bindings for LOWA using embind. Adds new parameter '-W' to cppumaker to generate _embind.cxx files alongside .hdl & .hpp. For usage examples see static/README.wasm.md Change-Id: Iee5d05e37bfba8e101c08212b15c05f7f2fa6c33 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/156273 Tested-by: Jenkins Reviewed-by: Sarper Akdemir <sarper.akdemir.extern@allotropia.de> 2022-12-23Don't use symlinks for the Emscripten soffice.data and soffice.data.js.metadataTor Lillqvist Symlinks just complicate things. Disk space is cheap. soffice.data is under 100 megs even with Qt5. Note that after this you will need to clean out the existing soffice.data and soffice.data.js.metadata symlinks before you run make, otherwise you will get errors. As such, it is a bit weird that we unconditionally play around with soffice.data for *all* (non-CppunitTest) Executable targets. (Thus, for instance also for vcldemo and unoidl-read.) We should do this dance only for the soffice executable. And we should reduce the number of executables we build for Emscripten. Probably none other than soffice itself makes sense? Change-Id: I75f6719b92d83e88bf59d65c38aeeab47e0b29e1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144781 Tested-by: Jenkins Reviewed-by: Tor Lillqvist <tml@collabora.com> 2022-12-23Un-confuse Emscripten and Qt5 conditionalsTor Lillqvist The embedded file system that we construct when building for Emscripten is not related to whether we use Qt5 or not. Change-Id: Ibf65cae06093d9130a19780c1116f8b9997c664b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144780 Reviewed-by: Tor Lillqvist <tml@collabora.com> Tested-by: Tor Lillqvist <tml@collabora.com> 2022-12-22gb_LTOFLAGS: use -flto=jobserver instead of fixed $(PARALLELISM)Christian Lohmaier fixed PARALLELISM causes explosion of jobs, especially when machines wtih many cores/threads. A make wtih PARALLELISM=16 would launch up to 16 linker invocations that by themselves would also do their linking with a parallelism of 16, causing load of over 100 and very likely exhausting all memory bringing the system to a crawl or cause OOM kills. for a command to be able to communicate with make's jobserver, it must be part of a submake called with $(MAKE) or the command from the rule needs to be prefixed with the + character. While our gbuild stuff is a submake call, it only is that submake that uses the PARALLELISM flags determined by configure, so that is not sufficient for jobserver usage by the the lto linker. Change-Id: I46ec4760c1a8623195700b8cb16f7deafeb1111e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/144593 Tested-by: Jenkins Reviewed-by: Christian Lohmaier <lohmaier+LibreOffice@googlemail.com> 2022-11-28WASM gbuild: write link dependencies into a file $@.linkdepsMichael Stahl The static build was added in commit dc9ccf3d8f294cd7ae9d5bece7b6c16c3b22f6a5 and commit b04be559ddf4a7f0a5cdc0b9abc2bcfc4aae25cc and there are several files written to workdir/LinkTarget/*/*.d.{libraries,externals,statics} that list all the (recursive) dependencies of a LinkTarget. Unfortunately the content of these files requires gbuild to interpret, because it's using the Library names which may not map 1:1 to file names, not to mention "externals"; this is all resolved by calls to gb_LinkTarget_use_* anyway. To get a command line that's usable outside of gbuild, write another file $@.linkdeps as a side effect of gb_LinkTarget__command_dynamiclink. Change-Id: I94f31142413561dcdb56fa722a4517f84fcd7d61 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143393 Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Tested-by: Jenkins 2022-11-28WASM gbuild: avoid annoying python warnings from emscriptenMichael Stahl /home/builder/emsdk/upstream/emscripten/tools/building.py:1228: ResourceWarning: unclosed file <_io.BufferedReader name='/data/lo/build_feature_wasm/workdir/LinkTarget/StaticLibrary/libdtoa.a'> header = open(filename, 'rb').read(8) ResourceWarning: Enable tracemalloc to get the object allocation traceback Change-Id: I5cd052cd47af92e18cb6ccce31d4503a322d815b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/143389 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> 2022-05-01improve support for using libc++ on Linux and for libc++ debug modeLuboš Luňák It seems to run slightly faster in --enable-dbgutil mode and also builds a bit faster (at least with Clang). But libc++ on Mac isn't built with debug mode support. Change-Id: Idf5dba9c4a56aba1f4163aa518a78d34b6837149 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/133664 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2022-02-24Don't run ExternalExecutable_python with LD_LIBRARY_PATHStephan Bergmann 257bcb1a1140d3e070cfaef6fec0704740bc83b8 "get internal python invocations working" had made this use LD_LIBRARY_PATH or similar on the various platforms, but without giving any reason what it would actually be good for. 5d8f48c81eac8650315b936d0e89ad1d54b566fc "solver doesn't solve anything..." then (somewhat by chance?) removed it for solenv/gbuild/platform/macosx.mk, apparently without loss of functionality, but left it intact for other platforms. But at least in some Jenkins Linux build environments presence of LD_LIBRARY_PATH (pointing at instdir/program/) appears to cause subtle problems: Builds like <https://ci.libreoffice.org/job/lo_tb_master_linux/49844/> occasionally crashed with [...] > make -O [...] > [build PAT] python3 > [build PRJ] python3 [...] > [build PKG] python3 > [build EPK] python3 [...] > [build BIN] python3 [...] > [build MOD] python3 [...] > [build PRJ] nss [...] > make[1]: *** Deleting file '/home/tdf/lode/jenkins/workspace/lo_tb_master_linux/workdir/UIConfig/sfx.a11yerrors' > [build UIA] sfx > Suppression file: /home/tdf/lode/jenkins/workspace/lo_tb_master_linux/solenv/sanitizers/ui/sfx.suppr > False positive file: /home/tdf/lode/jenkins/workspace/lo_tb_master_linux/solenv/sanitizers/ui/sfx.false > sfx2/uiconfig/ui/documentinfopage.ui: WARNING: 'GtkLabel' 'label8' does not specify what it labels within 'interface' > 1 new warning (64 suppressed by /home/tdf/lode/jenkins/workspace/lo_tb_master_linux/solenv/sanitizers/ui/sfx.suppr, please fix them) > 0 new fatals (12 suppressed by /home/tdf/lode/jenkins/workspace/lo_tb_master_linux/solenv/sanitizers/ui/sfx.suppr, please fix them) > Explanations are available on https://wiki.documentfoundation.org/Development/Accessibility > > /bin/sh: line 1: 31655 Segmentation fault (core dumped) LD_LIBRARY_PATH=${LD_LIBRARY_PATH:+$LD_LIBRARY_PATH:}"$I/program:$I/program" PYTHONHOME="$I/program/python-core-3.8.12" PYTHONPATH="${PYPATH:+$PYPATH:}$I/program/python-core-3.8.12/lib:$I/program/python-core-3.8.12/lib/lib-dynload" $I/program/python.bin $S/bin/gla11y -P $S/ -f $S/solenv/sanitizers/ui/sfx.false -s $S/solenv/sanitizers/ui/sfx.suppr --widgets-suffixignored +ValueSet,HBox,VBox,ToolBox,Preview,PreviewWin,PreviewWindow,PrevWindow --widgets-button +svtlo-ManagedMenuButton --fatal-all --not-fatal-type duplicate-mnemonic --not-fatal-type labelled-by-and-mnemonic --not-fatal-type orphan-label -o $W/UIConfig/sfx.a11yerrors $S/sfx2/uiconfig/ui/alienwarndialog.ui $S/sfx2/uiconfig/ui/addtargetdialog.ui $S/sfx2/uiconfig/ui/autoredactdialog.ui $S/sfx2/uiconfig/ui/bookmarkdialog.ui $S/sfx2/uiconfig/ui/bookmarkmenu.ui $S/sfx2/uiconfig/ui/charmapcontrol.ui $S/sfx2/uiconfig/ui/charviewmenu.ui $S/sfx2/uiconfig/ui/checkin.ui $S/sfx2/uiconfig/ui/classificationbox.ui $S/sfx2/uiconfig/ui/cmisinfopage.ui $S/sfx2/uiconfig/ui/cmisline.ui $S/sfx2/uiconfig/ui/commandpopup.ui $S/sfx2/uiconfig/ui/custominfopage.ui $S/sfx2/uiconfig/ui/deck.ui $S/sfx2/uiconfig/ui/descriptioninfopage.ui $S/sfx2/uiconfig/ui/developmenttool.ui $S/sfx2/uiconfig/ui/devtoolsmenu.ui $S/sfx2/uiconfig/ui/documentfontspage.ui $S/sfx2/uiconfig/ui/documentinfopage.ui $S/sfx2/uiconfig/ui/documentpropertiesdialog.ui $S/sfx2/uiconfig/ui/editdocumentdialog.ui $S/sfx2/uiconfig/ui/editdurationdialog.ui $S/sfx2/uiconfig/ui/emojicontrol.ui $S/sfx2/uiconfig/ui/extrabutton.ui $S/sfx2/uiconfig/ui/errorfindemaildialog.ui $S/sfx2/uiconfig/ui/floatingrecord.ui $S/sfx2/uiconfig/ui/helpbookmarkpage.ui $S/sfx2/uiconfig/ui/helpcontrol.ui $S/sfx2/uiconfig/ui/helpcontentpage.ui $S/sfx2/uiconfig/ui/helpindexpage.ui $S/sfx2/uiconfig/ui/helpmanual.ui $S/sfx2/uiconfig/ui/helpsearchpage.ui $S/sfx2/uiconfig/ui/helpwindow.ui $S/sfx2/uiconfig/ui/infobar.ui $S/sfx2/uiconfig/ui/inputdialog.ui $S/sfx2/uiconfig/ui/licensedialog.ui $S/sfx2/uiconfig/ui/linefragment.ui $S/sfx2/uiconfig/ui/linkeditdialog.ui $S/sfx2/uiconfig/ui/loadtemplatedialog.ui $S/sfx2/uiconfig/ui/managestylepage.ui $S/sfx2/uiconfig/ui/navigator.ui $S/sfx2/uiconfig/ui/newstyle.ui $S/sfx2/uiconfig/ui/notebookbar.ui $S/sfx2/uiconfig/ui/optprintpage.ui $S/sfx2/uiconfig/ui/panel.ui $S/sfx2/uiconfig/ui/password.ui $S/sfx2/uiconfig/ui/notebookbarpopup.ui $S/sfx2/uiconfig/ui/printeroptionsdialog.ui $S/sfx2/uiconfig/ui/querysavedialog.ui $S/sfx2/uiconfig/ui/saveastemplatedlg.ui $S/sfx2/uiconfig/ui/safemodequerydialog.ui $S/sfx2/uiconfig/ui/searchdialog.ui $S/sfx2/uiconfig/ui/securityinfopage.ui $S/sfx2/uiconfig/ui/singletabdialog.ui $S/sfx2/uiconfig/ui/startcenter.ui $S/sfx2/uiconfig/ui/stylecontextmenu.ui $S/sfx2/uiconfig/ui/tabbar.ui $S/sfx2/uiconfig/ui/tabbarcontents.ui $S/sfx2/uiconfig/ui/tabbutton.ui $S/sfx2/uiconfig/ui/templatedlg.ui $S/sfx2/uiconfig/ui/templatecategorydlg.ui $S/sfx2/uiconfig/ui/templatepanel.ui $S/sfx2/uiconfig/ui/urlbox.ui $S/sfx2/uiconfig/ui/versionsofdialog.ui $S/sfx2/uiconfig/ui/versioncommentdialog.ui $S/sfx2/uiconfig/ui/versionscmis.ui > /home/tdf/lode/jenkins/workspace/lo_tb_master_linux/solenv/gbuild/UIConfig.mk:157: recipe for target '/home/tdf/lode/jenkins/workspace/lo_tb_master_linux/workdir/UIConfig/sfx.a11yerrors' failed > make[1]: *** [/home/tdf/lode/jenkins/workspace/lo_tb_master_linux/workdir/UIConfig/sfx.a11yerrors] Error 139 > make[1]: *** Waiting for unfinished jobs.... where the crashed instdir/program/python.bin is at > (gdb) thread apply all backtrace > > Thread 1 (Thread 0x2af0920e1a40 (LWP 30414)): > #0 0x0000000000000ae0 in ?? () > #1 0x00002af0920b008a in _dl_fini () from /lib64/ld-linux-x86-64.so.2 > #2 0x00002af093404ce9 in __run_exit_handlers () from /lib64/libc.so.6 > #3 0x00002af093404d37 in exit () from /lib64/libc.so.6 > #4 0x00002af0933ed55c in __libc_start_main () from /lib64/libc.so.6 > #5 0x000000000040068e in _start () with > (gdb) info sharedlibrary > From To Syms Read Shared Object Library > 0x00002af09232e2f0 0x00002af09253270c Yes /home/tdf/lode/jenkins/workspace/lo_tb_master_linux/instdir/program/libpython3.8.so.1.0 > 0x00002af09286fe30 0x00002af092874cec Yes (*) /lib64/libcrypt.so.1 > 0x00002af092aab8f0 0x00002af092ab6db1 Yes (*) /lib64/libpthread.so.0 > 0x00002af092cc2e50 0x00002af092cc394e Yes (*) /lib64/libdl.so.2 > 0x00002af092ec6e90 0x00002af092ec77a4 Yes (*) /lib64/libutil.so.1 > 0x00002af0930ce350 0x00002af093139336 Yes (*) /lib64/libm.so.6 > 0x00002af0933ea9f0 0x00002af09353ab6f Yes (*) /lib64/libc.so.6 > 0x00002af093799a50 0x00002af09379a05a Yes (*) /home/tdf/lode/jenkins/workspace/lo_tb_master_linux/instdir/program/libfreebl3.so > 0x00002af0920a0af0 0x00002af0920bc060 Yes (*) /lib64/ld-linux-x86-64.so.2 > 0x00002af09a0e3be0 0x00002af09a10aa53 Yes /home/tdf/lode/jenkins/workspace/lo_tb_master_linux/instdir/program/python-core-3.8.12/lib/lib-dynload/pyexpat.cpython-3.8.so What is suspicious is that it uses instdir/program/libfreebl3.so when external/nss has been built ("[build PRJ] nss") but has not yet been fully delivered (no "[build PKG] nss"). It uses instdir/program/libfreebl3.so because on that machine instdir/program/python.bin has a DT_NEEDED of libcrypt.so.1 and /lib64/libcrypt.so.1 has a DT_NEEDED of libfreebl3.so, which the LD_LIBRARY_PATH then resolves with instdir/program/libfreebl3.so rather than with the expected /lib64/libfreebl3.so. So remove setting of LD_LIBRARY_PATH on all the platforms where it was still used, in the hope that it isn't actually necessary on any of them. Only on Windows, setting PATH is still needed (in line with how the Executable_python wrapper modifies it too) to avoid build failures like > instdir/program/python-core-3.8.12/bin/python.exe: error while loading shared libraries: python38_d.dll: cannot open shared object file: No such file or directory Change-Id: I398aa89166a6a7f3db58c4e65237840b73bec74b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130470 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-02-17Drop -Wdeclaration-after-statementStephan Bergmann It was introduced, without a rationale, into unxgcc.mk in eb09adaa9a2accbdc3531bb96447c8e7fbb9f8a9 "Warn if declaration follows statement in C-files", then carried over to clang-cl (com_MSC_defs.mk) with 9055fb48402eaeb9ba876b7893e2f9a39fea06b1 "clang-cl: Enable more warnings etc. (like in the Clang/GCC case)", where it now started to cause > cppuhelper/source/findsofficepath.c(102,20): error: mixing declarations and code is incompatible with standards before C99 [-Werror,-Wdeclaration-after-statement] > const wchar_t* SUBKEYNAME = L"Software\\LibreOffice\\UNO\\InstallPath"; > ^ after <https://github.com/llvm/llvm-project/commit/118f966b46cfb60897b56a9878e1c68fd0e2afa4> "[clang][#51931] Enable -Wdeclaration-after-statement for all C versions". Lets remove it from all toolchain settings, there appears to be not much value anymore in such a warning about pre-C99 code. Change-Id: Id4669089e46c97aaa926e5bd202c36eb5984b837 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/130058 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2022-01-19WASM create and link the Emscripten FS imageJan-Marek Glogowski There are three posibilites to add files to the image: - gb_emscripten_fs_image_files to add individual files - gb_emscripten_fs_image_autoinstall to add files from AutoInstall - gb_emscripten_fs_image_filelists to add files from a .filelist Change-Id: If6804e282a37a37ffae1d291d2af8430e60b59d1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128598 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2022-01-19WASM gbuild: add --pre-js dependenciesJan-Marek Glogowski Currently includes environment.js for general environment settings and soffice_args.js for soffice command line flags. Change-Id: I1166c5a9ae53c56a69b9223c865b4df525d07450 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128590 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2022-01-19WASM more initial bits and piecesJan-Marek Glogowski All the small stuff, which is needed for the WASM build, but is not really worth an extra patch. * No soffice.sh script needed for WASM * WASM soffice.bin executable extension is html * Some small additional SAL_LOG output * Default to colibre icon theme * Test for qt5 even without X11 * Remove emconfigure artefacts at the end of the configure run * No oosplash for WASM * Disable the Office IPC thread * Suppress -Wno-enum-conversion for Cairo builds * Fix libnumbertext by using gb_EMSCRIPTEN_CPPFLAGS * Map EMSCRIPTEN to LINUX nls * No extra newlines for missing icon theme images * Print the missing dependency in some gbuild error messages * Copy Qt WASM loader, HTML template and SVG logo for binaries * Especially build the vcldemo for Emscripten Change-Id: I356370c72cc09357411e14d0c00762152877a800 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128584 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2022-01-12Fix typosAndrea Gelmini Change-Id: I47fc636e0b69b72fb6ca247f9e0cbabbddb3985e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128321 Tested-by: Julien Nabet <serval2412@yahoo.fr> Reviewed-by: Julien Nabet <serval2412@yahoo.fr> 2022-01-12gbuild: build static LO / link static executablesJan-Marek Glogowski This allows to build a complete static LibreOffice on Linux, except for linked externals. Since LO's static build implies disabled dynamic loading, one must select one VCL backend to be compiled in. See the (large) comment in solenv/gbuild/static.mk trying to explain, why this implementation was chosen (spoiler: seems there is no other way) and what is actually implemented. This will collect all libraries, statics and externals of executables. If the executable uses components, it will get linked to all static components. While it works with any Executable, it just makes sense for soffice.bin, because the static component map sucks every dependency in, bloating most other binaries. In theory on could generate the dependencies based on the list of used components (see gb_CppunitTest_use_components), then generate a specific static constructor map, directly include it in the exe's cxx code and then link the minimal dependencies. The static LO should build on Linux with: --enable-customtarget-components --disable-dynamic-loading Tested VCL plugin config is: --disable-gtk3 --disable-gen --enable-qt5 The partial build support is split into a 2nd patch. Change-Id: Iafc95752fae9e88095f54a21f1e30a4f080815e2 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126790 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de> 2022-01-08Unify condition names and fix "else" pathsJan-Marek Glogowski Drop Build prefix and settle on Lib and Exe prefixes. Also add a note about the "else" part of the condition and fix offenders. While at it, define COND_LIB_SAL_TEXTENC to be used by sal to prevent diverting coditions in build and cxx code. Change-Id: I944587ca1ccbe46b765d1a631a7214c8126fe951 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128136 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2021-12-30oss-fuzz: chain-depend all *fuzzer binariesJan-Marek Glogowski Change-Id: Id92ae26db0c4321f1670f7bd6d8c03c521e18d93 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127712 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2021-12-28gbuild: announce date when acquiring the link lockJan-Marek Glogowski Must use echo, because we're in the shell at this point. Change-Id: I576ae2afe743b11a11bc776e5fa19a1904bbd1fe Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127610 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2021-12-15lockfile: use a single build conditionJan-Marek Glogowski ... and introduce solenv/gbuild/Conditions.mk The Conditions.mk is included just after the Helpers.mk, which should make its content available basically everywhere. Change-Id: Ie4498e12b3d0f676ed0c9abf4b3bb4899d6a1c03 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126787 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2021-12-13Refactor some buildsytem stuff (mostly whitespace)Jan-Marek Glogowski Change-Id: Idfca786ecc7251e08525bd5b45936143727c43d3 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126731 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2021-12-06don't want to link to system static libs for DISABLE_DYNLOADINGCaolán McNamara since... commit 4250958a492b300a52a83e68dd599f9c36c5086e Author: Caolán McNamara <caolanm@redhat.com> Date: Fri Aug 20 14:31:36 2021 +0100 ofz: prep for allowing oss-fuzz msan dependencies need to be built with the msan flags so undo the --with-system .a usage now that trying to squeeze into the 12 hour build window isn't critical because the afl 6-8 hour build+check is disabled dropped the use case for that Change-Id: Ic525c9e0a948195cc823d904ba5a0d80b3aff668 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126455 Tested-by: Jenkins Reviewed-by: Caolán McNamara <caolanm@redhat.com> 2021-12-06Limit static system library linking to fuzzersJan-Marek Glogowski When building a static LO on Linux, I get a lost of missing symbols for binaries, like oosplash. In that case we just link to Xinerama, but this has obviously other X11-based dependencies, and there is no real way to fix this. According to caolan, this was just added in commit 7a3eaef6dd707781c2f4e341aebb9d4c42df780f ("for DISABLE_DYNLOADING support linking to static .a system libs") to support instrumented static libraries used for the oss-fuzz runs (see https://github.com/google/oss-fuzz/issues/608). So actually limit these flags for FUZZERS only. Change-Id: I7eaa81c46fab040848fdf4dbe100a6e634f54446 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126409 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 2021-12-01gbuild: serialize dynamic link for static buildsJan-Marek Glogowski This is a hack, because make has no way to serialize processing of a target (just .NOTPARALLEL for the whole Makefile). It uses the lockfile tool / liblockfile 1.17. Since that polls the file, I adjusted the poll timeout to 5s max, because I found the 60s wait much too long. Guess even 1s would be ok... Since it's just a small build tool, I simply copied and patched its source, instead of creating an external project. And there is --with-system-lockfile=... to use an external binary instead. Change-Id: I16bc4579a273dcf1aac811ae4723ca325a0b9eba Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126152 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de> 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-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-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-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-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-03-09Run gdb in `make debugrun` with PYTHONWARNINGS=default, tooStephan Bergmann ...same as fb06d5b1784cb8b91ea6d286b3f2baa38fed0b4c "Run gdb with PYTHONWARNINGS=default" Change-Id: I1f4a5a7851cbb6f35c25684bb122bb90364ce334 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/112204 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-08-25dont turn on malloc debugging for gdb itselfNoel Grandin fix the command such that, when we insert the malloc debugging env vars, we only do it for the executable itself, not for gdb, or some gdb operations will be very very slow. Before this fix, if I did a make Cppunit... CPPUNITRACE=... ran the program, then ran it again, the second time would take 5 min to get going. Now the second time it runs in seconds. Change-Id: Id08c3a82679164588b88af65a6a7b5f7dd19ff05 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/101318 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk> 2020-08-12Enable --enable-lto --enable-skia when building with GCC+Clang on LinuxStephan Bergmann ...where all the Library_skia objects are built with Clang, so contain intermediate LLVM bytecode, but were then linked via GCC and ld or gold, which do not understand such object files and thus failed. So in gb_LinkTarget__command_dynamiclink use T_CC/T_CXX also for the linker command line. But then Clang would still be used for linking with the -fuse-ld=(ld or gold) $(USE_LD) suitable for GCC, and would still fail. So break T_USE_LD out of T_LDFLAGS and let gb_LinkTarget_use_clang override T_USE_LD with CLANG_USE_LD. At least for now, that CLANG_USE_LD (containing something like -fuse-ld=lld or -fuse-ld=lld --ld-path=... for the latter see d668c9a04d04d256fcbbd2165fe226f1db88256b "Adapt --enable-ld to Clang 12 trunk --ld-path") needs to manually be passed into autogen.sh, it is not computed in configure.ac. Then building Library_skia would still fail to link against StaticLibrary_libpng, as that only contains intermediate GCC object code, so make sure to build it with -ffat-lto-objects in this specific case. Change-Id: I0a104e53a8898cd9c2eb3b643e21954e853608cc Reviewed-on: https://gerrit.libreoffice.org/c/core/+/100556 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2020-02-16GBUILD_TRACE, support for finding out where the build time is spentLuboš Luňák See instructions in solenv/gbuild/Trace.mk . This generates a file than can be viewed e.g. in the Chromium tracing view. Change-Id: I5f90647c58ca729375525b6daed2d4918adc8188 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88754 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2019-09-20Remove legacy NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY supportStephan Bergmann ...for ASan/UBSan builds using Clang older than current trunk twoards Clang 9, as announced at <https://lists.freedesktop.org/archives/libreoffice/2019-May/082654.html> "Re: [Libreoffice-commits] core.git: The -fvisibility-ms-compat hack is no longer needed for UBSan on Linux...". (And drop the no longer needed solenv/sanitizers/asan-suppressions, which people might still reference from their ASAN_OPTIONS.) Change-Id: Iedc0c5955366d2cbe7dc847990e2b1576750e85b Reviewed-on: https://gerrit.libreoffice.org/72493 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-09-02Add -latomic to the end of Linux C++ linker command linesStephan Bergmann b11763dbaa0c7f427ea47abe9b98995cb49a8595 "link with -latomic on mips(el), armel, powerpc, m68k" had added -latomic to the linker command lines of just some Linux platforms (which apparently happened to actually require it). But there were three issues with that: * The -latomic came too early on the command line, so that it wasn't used to satisfy dependencies of .o files that came later. See the discussion at <https://gerrit.libreoffice.org/#/c/78319/> "set -Wl,--no-as-needed for -latomic". * There is presumably no need to include -latomic on C linker command lines. * <https://gcc.gnu.org/onlinedocs/gcc-7.3.0/libstdc++/manual/manual/using.html #manual.intro.using.flags> (matching our Linux libstdc++ 7.3.0 baseline as per README.md) states: "Linking to libatomic is required for some uses of ISO C++11 <atomic>." So we should better include -latomic on every Linux C++ linker command line that uses libstdc++. (This patch assumes that we always use libstdc++ on Linux.) Ideally we could rely on -latomic always being available with our baseline libstdc++ 7.3.0, but when using Red Hat Developer Toolset 7 that appears not to be the case, as reported by a Jenkins build for an older version of this change (see below), so use ATOMIC_LIB from the preceding commit <https://gerrit.libreoffice.org/#/c/78336/> "add -latomic configure check...". <https://ci.libreoffice.org/job/gerrit_linux_gcc_release/40298/console>: > [build LNK] Executable/unoapploader > /opt/rh/devtoolset-7/root/usr/libexec/gcc/x86_64-redhat-linux/7/ld: cannot find -latomic > collect2: error: ld returned 1 exit status > /home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/solenv/gbuild/LinkTarget.mk:636: recipe for target '/home/tdf/lode/jenkins/workspace/lo_gerrit/Config/linux_gcc_release_64/workdir/LinkTarget/Executable/idxdict' failed This patch adds -latomic only on Linux. Similar changes can be made for other platforms if need be. Change-Id: I75df5410677f4c31c796d7ba85532bcdb47eb111 Reviewed-on: https://gerrit.libreoffice.org/78380 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-05-03The -fvisibility-ms-compat hack is no longer needed for UBSan on Linux...Stephan Bergmann ...with latest Clang trunk towards Clang 9. All the no-longer necessary hacks are made conditional on new NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY, which is still set for UBSan builds with older Clang on Linux (but which should eventually be purged). Various classes needed additional SAL_DLLPUBLIC_RTTI annotations, as building with UBSan instrumentation can generate references to RTTI symbols from additional places like outside a dynamic library that used to hide those symbols by default (but used to not hide them for old UBSan builds thanks to the -fvisibility-ms-compat hack). The odr-violation suppressions in solenv/sanitizers/asan-suppressions (which is not referenced from anywhere in the code base, but meant to be included in an ASan/UBSan build's ASAN_OPTIONS env var) are also no longer needed when NEED_CLANG_LINUX_UBSAN_RTTI_VISIBILITY is false. Change-Id: I24ec3e388b0cbab50dbe2bf008d9569bff7bf25a Reviewed-on: https://gerrit.libreoffice.org/70829 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-04-25Cut down on -pthread/-lpthread proliferationStephan Bergmann Building against libstdc++ effectively always requires -pthread anyway (as various standard C++ headers require it, see the comment added to solenv/gbuild/platform/unxgcc.mk), so many explicit uses of -pthread/-lpthread can be removed. Doing a (partial) test build on Linux with Clang -stdlib=libc++ suggests that libc++ indeed doesn't need -pthread as libstdc++ does. The remaining uses of -pthread/-lpthread are mostly in configure.ac for the various BSDs (which somebody else might want to clean up now), and related to external projects. I tried to be careful to remove -pthread/-lpthread from makefiles only when C++ object files are involved (so -pthread will now be included on the link command line by default). Change-Id: I936e082839cb9a434bd273ce5a1f187a4245dfa1 Reviewed-on: https://gerrit.libreoffice.org/71291 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com> 2019-04-11make linker flags conditional when used, not when definedLuboš Luňák gb_LINKEROPTFLAGS and gb_LINKERSTRIPDEBUGFLAGS are only used by gb_LinkTarget__get_debugldflags, which already properly uses them depending on whether debuginfo is wanted or not Change-Id: I0befc10d6f1ee99ccd49a640241e3ae023454875 Reviewed-on: https://gerrit.libreoffice.org/70366 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com> 2018-07-05UBSan apparently still needs --dynamic-list-cpp-typeinfoStephan Bergmann ...(presumably due to it using -fvisibility-ms-compat, cf. solenv/gbuild/platform/com_GCC_defs.mk), or else things start to fail like <https://ci.libreoffice.org/job/lo_ubsan/962/console>'s CustomTarget_testtools/uno_test: > /cpputools/source/unoexe/unoexe.cxx:502:24: runtime error: member call on address 0x60600000c288 which does not point to an object of type 'com::sun::star::lang::XMain' > 0x60600000c260: note: object is base class subobject at offset 40 within object of type 'bridge_test::TestBridgeImpl' > #0 0x50dc0b in sal_main() /cpputools/source/unoexe/unoexe.cxx:502:24 > #1 0x507762 in main /cpputools/source/unoexe/unoexe.cxx:348:1 > #2 0x2b2ede591444 in __libc_start_main (/lib64/libc.so.6+0x22444) > #3 0x429425 in _start (/instdir/program/uno.bin+0x429425) Change-Id: I7f2c38ef2f3cedae07d71246980ad1f21220db72 2018-07-04drop usage of --dynamic-list-cpp-new/typeinfoLuboš Luňák First of all, lld doesn't have these options, but there doesn't seem to be any point in using them anyway. They are supposed to block the effect of -Bsymbolic-functions, but: - --dynamic-list-cpp-new matters only if we'd create our own global operator new/delete, which we don't - --dynamic-list-cpp-typeinfo affects only the typeinfo (_ZTI*) and typeinfo name (_ZTS*) symbols, which are not functions, and so -Bsymbolic-functions shouldn't do anything with them. According to https://sourceware.org/bugzilla/show_bug.cgi?id=3831 my understanding is that --dynamic-list-cpp-typeinfo actually predates -Bsymbolic-functions and it was an attempt to do the same from the other direction ('bind locally everything except for this' instead of 'bind locally only functions'). Change-Id: Iadad2d78f32a2adfb9c2100fb4eb5abe75725545 Reviewed-on: https://gerrit.libreoffice.org/56739 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Luboš Luňák <l.lunak@collabora.com> 2018-02-28Build external lxml if not provided by systemSamuel Thibault except on windows, where gla11y will resort to python's internal xml parser, which does not provide line numbers. This allows gla11y to be runnable on all systems. Change-Id: Ica4eb90f59bddfcefd783fc2ed9c8c27357e7572 Reviewed-on: https://gerrit.libreoffice.org/50115 Tested-by: Jenkins <ci@libreoffice.org> Reviewed-by: Stephan Bergmann <sbergman@redhat.com>