summaryrefslogtreecommitdiff
path: root/solenv/gbuild/LinkTarget.mk
AgeCommit message (Collapse)Author
2022-03-28Drop support for OpenGL denylist on X11Stephan Bergmann
...which appears to have become even less relevant with db89f53c31af997b9bf422b0e784afba8d62a42e "remove OpenGL VCL backend code". And the vcl/unx/glxtest.cxx machinery that it is based on is (a) known to cause issues like <https://gitlab.freedesktop.org/mesa/mesa/-/issues/3957> "LibreOffice's OpenGL version detection code hangs when running inside a flatpak container with a different mesa version", and (b) is one of the two reasons why an soffice that uses Wayland nevertheless also requires Xwayland during startup (the other reason being oosplash). So getting rid of the glxtest machinery is beneficial. The remaining two potential uses of OpenGL on X11/Wayland are the obscure css.rendering.SpriteCanvas.OGL service implementation (about which db89f53c31af997b9bf422b0e784afba8d62a42e states that "it seems has never been finished or enabled (or so it most probably should be dumped too)") and some slideshow transitions. About the latter, Caolán stated on IRC: "I think we grew this set of stuff to check for dodgy opengl primarily for the case where vcl used opengl for ordinary UI optimizations; but I think that use is gone now so I wonder does it make sense to just drop all of that entirely; for just slide transitions we apparently survived fine without the denylist for ages". (And in any case there is still the WatchdogThread support with OpenGLZone::hardDisable in VCLExceptionSignal_impl, vcl/source/app/svmain.cxx, should any OpenGL code run into problems.) (The removal of gb_LinkTarget_use_glxtest from gb_LinkTarget_use_vclmain, which indirectly brought in gb_LinkTarget_use_libraries,*,vcl, revealed that an explicit use of vcl was missing from various Executables etc., which thus had to be added now.) Change-Id: Ifa5220fd09910a4459ca546d9655e479a2e38f1e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/131943 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-26gbuild: fix spurious rebuilds from gb_LinkTarget__use_librariesMichael Stahl
Apparently the eval inside of "ifeq" needs to be escaped, currently both branches of the "ifeq" are evaluated and generate makefile dependencies, which causes spurious rebuild of Library_salhelper with DISABLE_DYNLOADING unset from: make Library_salhelper && touch -c ../master/sal/osl/all/compat.cxx && make Library_salhelper (regression from ecc50f56b3282ec3b0364101d860f22fe8da9042) Change-Id: I8b5607b7a172c8b4b05abeaf4d5ff3a68d53cb14 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128930 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-19Let CppunitTest_odk_checkapi build against the SDK include directoryStephan Bergmann
...which contains only the URE include files, rather than against the SRCDIR one which contains many more. This would have prevented 148536afc9838398100ca2267b99ab349dcbb38c "Drop config_global.h from osl/module.h", where an URE include file had accidentally started to include a non-URE file. (The way $(INCLUDE) is now set up in odk/CppunitTest_odk_checkapi.mk is a bit hacky, and this change required teaching compilerplugins about SDKDIR to avoid false warnings. Another approach would be to make the test compile in the SDK build environment, similarly to CustomTarget_odk/build-examples, but setting up the SDK build environment from within gbuild is not supported at least on Windows for now. A smaller improvement would be to drop the need to include any CppUnit include directories, by turning the test into some kind of compile-only test similar to a gb_CompilerTest.) Change-Id: If79761909c67c3162d01f847dfb5d4f538f91ca1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128591 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2022-01-19Decouple SRCDIR/include from SOLARINCStephan Bergmann
...turning the latter into "whatever include directories are needed for the given toolchain and platform, outside the scope of LibreOffice". This is a prerequisite for fixing <https://gerrit.libreoffice.org/c/core/+/128591/1> "Let CppunitTest_odk_checkapi build against the SDK include directory", which failed to find the C++ standard library headers (available via SOLARINC) on Windows. (In external/icu/ExternalProject_icu.mk, SRCDIR/include is needed for ANDROID to find <android/compatibility.hxx> in external/icu/icu4c-android.patch.1.) Change-Id: I960e31140b0839b2b6184a78d935042c3c558d5b Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128615 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
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-18Add HAVE_(UNIX_)DLAPI config header defineJan-Marek Glogowski
..., add the configure test flags and rename DLOPEN_LIBS to UNIX_DLAPI_LIBS. Initinally convert two dlsym callers to use HAVE_DLAPI and osl_getAsciiFunctionSymbol. There are a lot of places, which still use -ldl and even more direct dlsym calls; good opportunity for many simple EasyHacks. Change-Id: I4f2d2f7cb079a075af8f9d01eb5ee45de40c7f03 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128523 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-13gbuild: implement static partial buildJan-Marek Glogowski
This stores all the dependencies collected from the full build, and uses that info to link static binaries in per module. Change-Id: I27bd41c217bf0d2248ee88004038dd6b813f2624 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/128129 Tested-by: Jenkins Reviewed-by: Michael Stahl <michael.stahl@allotropia.de> Reviewed-by: Thorsten Behrens <thorsten.behrens@allotropia.de>
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-07gbuild: fix actually used libraries for mergelibJan-Marek Glogowski
Just the $(filter $(gb_MERGEDLIBS),$(2)) in the "if" was wrong, but reformat and add a comment to make the code easier to read. This way we correctly header-depend on all requested libraries, but just export-depend on the real libraries. And actually use gb_LinkTarget__is_build_lib in the ifeq, as otherwise the build now fails for the reduced dependencies. Change-Id: I24d5701891324f5055c9dfa535bd854d09fbb905 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127994 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-05gbuild: skip libmerged externals for partial buildsJan-Marek Glogowski
When running a full build, all externals of merged libraries are also added to libmerged when adding externals for the merged lib. Non-skipping for partial builds also breaks gbuildtojson, for all modules, which are merged and have additional libraries, tests or binaries, which then depend on the libmerged. This triggers for gbuildtojson, because the skipped %.exports now actually matter when checking the libmerged state. make then tries to rebuild it, but this can never work for a partial build, even with the full gbuild ruleset, not stripped by solenv/gbuild/extensions/post_GbuildToJson.mk. The totally confusing result, due to the mangled ruleset, is that the first externals %.exports overwrites libmerged in instdir. Change-Id: I2b72a8b543dbbd8c8f573bfe963164329bdd73e4 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127995 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-01gbuild: silence Windows Skia clang buildsJan-Marek Glogowski
When building Skia on Windows in an non-English environment, the console is filled with "Note: including file:" output. That's because cl.exe has some translated output, but clang.exe has not. So detect the clang usage and its "showIncludes" output and override that setting for the compiler call. Change-Id: I19b403aa79a8dde70616865aef051aa365f79de6 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127822 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2022-01-01oss-fuzz: depend on linktarget, not the binaryJan-Marek Glogowski
Not really an oss-fuzz-only problem, but general linking of static binaries. Broken in commit ecc50f56b3282ec3b0364101d860f22fe8da9042 ("gbuild: set library dependency for static builds"). Change-Id: Iba9c9405cf4adb78c1ec9b64dfa02c3a82d2cf55 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127800 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-31gbuild: introduce gb_%_linktarget_targetJan-Marek Glogowski
Just some refactoring. Change-Id: I47adb93f8a413d289f6abb2a48ed3f049f582a46 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127799 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-24gbuild: set library dependency for static buildsJan-Marek Glogowski
For DISABLE_DYNLOADING builds, all libraries become real and not export-only dependencies. And all real linking targets need a dependency on all static libraries. Change-Id: I8433a0225d428951739f7afa3068a61dce9e61eb Reviewed-on: https://gerrit.libreoffice.org/c/core/+/127236 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-13gbuild: forward / set linktargetmakefilenameJan-Marek Glogowski
Unfortunatly RepositoryExternal.mk ais generally not forwarding this info. It's also not really documented. Change-Id: I7920f7442521ab06f18c16397a13615e4517d053 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126730 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-03Fix --enable-mergelibs plugin dependencyJan-Marek Glogowski
Not sure why I didn't use gb_LinkTarget_use_libraries instead of the internal version. Regression from commit ed583bf8d553b145f83b66118253aaf7ac94fa1a ("gbuild: introduce plugin + loader concepts"). Change-Id: I600aee16c0c7296e14435c20ef4f47123db93a11 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126268 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-12-02Fix clang-cl -Zc:dllexportInlines- buildStephan Bergmann
That flag is only supported by clang-cl, not by MSVC, and c7c9f3f57a2feae5d3bc3c47104786883ed09e44 "use clang-cl's -Zc:dllexportInlines- for clang-cl builds" apparently naively assumed that it would work to build LO with clang-cl and that flag without actually trying it out, and 1040228c356d75c5228cde4d6103f9b446848e4b "My clang-cl build does not work with -Zc:dllexportInlines-" effectively disabled it completely. The way to avoid unresolved external symbols during linking of URE libraries (see the 1040228c356d75c5228cde4d6103f9b446848e4b commit message) is apparently to also build libraries that the URE libraries depend on with the flag, hence the change from gb_Library_set_is_ure_library to gb_Library_set_is_ure_library_or_dependency. For now, I only marked those additional libraries (unoil and xmlreader) that actually caused issues when linking the URE libraries. Change-Id: I3a85c73246250981cd86b7ee41f87b41f393a4b1 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126012 Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
2021-12-01gbuild: introduce plugin + loader conceptsJan-Marek Glogowski
This introduces two concepts: a plugin and its loader (library) LO currrently has dependency cycles for some libraries. There is scui, which depends on sc, while sc dlopen's scui. There are the various vclplug_*, i18npool plugins, filters/gie, acc, etc. Usually these plugins link to their loader library, because they use its symbols. But as a result there is no sensible way to express the runtime dependency of loaders on the plugins. In GNU libtool plugins are called modules and they are implemented in an IMHO more sensible way by allowing missing symbols at link time. This way you can have a dependency from the loader library to its plugins, as the plugins don't depend on the loader, but you lose the link time detection of missing symbols. While this is in theory possible in LO too, LO currently has plugins, like acc (accessibility), loaded by tk (toolkit), which depends on svt (svtools), which itself depends on tk, so dropping the tk dependency for acc on its own doesn't help :-( And while the dependency of the plugins on their loader is fine for the shared / DYNLOADING build, for the "static" builds you must (somehow) link the plugins into the executables. I also codeified a few rules into the build system along with it: * just plugins are allowed to depend / link other plugins * plugins aren't allowed to be linked into the merge lib * plugin loaders are "limited" to libraries At the high level, this is implemented via new gbuild calls: * gb_Library_set_plugin_for,lib,loader: declare a library to be a plugin of a loader library and add a dependeny from the plugin library to the loader library * gb_Library_set_plugin_for_nodep,lib,loader: ^^^^ without adding the library dependeny * gb_Helper_register_plugins_for_install: "plugin" replacement for gb_Helper_register_libraries_for_install to implement some additional checks in the build system In the end this patch just adds a bit syntactic sugar and nothing changes for any build. Change-Id: I7b01d9c384cbc5838bd2cc93aff18e4868939d6e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126163 Tested-by: Jenkins Reviewed-by: Jan-Marek Glogowski <glogow@fbihome.de>
2021-11-29fix shared PCH with clang-clLuboš Luňák
clang-cl does not understand -include CLI option. It also warns about #define's differing in the shared PCH that do not matter, so disable that. Change-Id: I9f6d7a8a28a8d290a8bf783f68c629c06cefbf41 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/126053 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-13do not rebuild PCHs on icecream/ccache changeLuboš Luňák
We turn -Wunused-macros on or off depending on whether icecream/ccache are used, and since now PCHs rebuild on CXXFLAGS changes, a plain temporary 'CCACHE_DISABLE=1' caused a rebuild. Change-Id: I63d539ac037d595f76a39e585011d1fde54f7f20 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125125 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2021-11-12rebuild a PCH when the flags it was built with changeLuboš Luňák
We already store the flags in a .flags file for another use, so just handle the file as another make rule before the PCH rule and if the file changes then the PCH rule will depend on something that has changed. Change-Id: Ic43068273a40c0337b77221660f370780a21340c Reviewed-on: https://gerrit.libreoffice.org/c/core/+/125094 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.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-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-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-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-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-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-05-26gbuild: Handle glxtest + vclmain usage via macrosJan-Marek Glogowski
Use a macro to do the same checks for all Executable with glxtest or vclmain usage. Both are static libraries, so every user has the same dependencies. Introduces: * gb_Executable_use_vclmain * gb_Executable_use_glxtest Change-Id: Ib80b4e7c6f5078d47ad8f1ec5708a7174415f705 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/116145 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-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-05-26Drop -I$(dir $(2)) also from gb_*Object__tool_commandStephan Bergmann
...after ecbaf980625a9e7b06abe91c7c70e78f6ad469a7 "-I$(dir $(3)) in gb_CObject__command_pattern is no longer needed" and f218f8f6c8c587d2d78679f935093329f145fede "-I$(dir $(3)) in gb_CObject__command_pattern is no longer needed" had already dropped it from plain gb_CObject__command_pattern. (0349c738da5970d9f0fc10d7cf4d7b766ce10e13 "support for compiler rewriters" had created gb_*Object__tool_command at a time when plain gb_*Object__command still contained those -I arguments, so had presumably just copied them over without a specific additional need to have them in the tool_command variants; and ecbaf980625a9e7b06abe91c7c70e78f6ad469a7 and f218f8f6c8c587d2d78679f935093329f145fede then just failed to also remove them from the tool_command variants.) Presence of the -I arguments in the tool_command variants caused e.g. `make COMPILER_PLUGIN_TOOL=fakebool` to fail with > sw/source/filter/ww8/ww8par.cxx:97:10: error: replace <...> include form with "..." for inclusion of a source file next to the current source file, sw/source/filter/ww8/../../core/inc/DocumentRedlineManager.hxx [loplugin:includeform] > #include <../../core/inc/DocumentRedlineManager.hxx> > ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ Change-Id: I7ef513507375dcee5d88db53cef58433f7f68e36 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/94867 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2020-04-21CLANG_C -> CLANG_CCLuboš Luňák
Change-Id: I50ed05116df3f295af6406f0ee45610d9e1e031e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92619 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-20prefer building Skia with Clang if possible (tdf#131697)Luboš Luňák
I.e. try to find and use Clang even if the default compiler is something else. Skia is optimized to be built with Clang(-cl) and in CPU-based raster mode some operations are several times slower if built with something else (e.g. fmax/fmin do not get optimized to inline assembly). It is enough to select Clang to be installed in the MSVS installer. At this point it unclear how to handle release binaries, if it should work this way and enforced, or maybe Clang could be used for building everything, or maybe some other way. Change-Id: I6b95a0f2d5cbf176942d9e01136990b14be6dba8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/92415 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-04-06use full path for the PCH .hxx file for MSCLuboš Luňák
Microsoft cl.exe actually doesn't care, but clang-cl without this complains that it cannot find the .hxx file for the PCH. Change-Id: Ic2db94f2323ddb884ea71e6ac6554cc0a5ab682a Reviewed-on: https://gerrit.libreoffice.org/c/core/+/91744 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-02-25fix --enable-mergedlibs buildNoel Grandin
after my recent additions to the list of libs exceeded Windows command line length limit (mostly affecting those people whose workspace was under a fairly long folder name) Change-Id: I4d60e9704db49f0a3f562200b737879fba7ee5a8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/89420 Tested-by: Jenkins Reviewed-by: Noel Grandin <noel.grandin@collabora.co.uk>
2020-02-19add --enable-optimized=debugLuboš Luňák
This will use -Og with GCC/Clang instead of -O0, which should make unittests run faster without (hopefully) breaking anything related to debugging. This is primarily meant to Jenkins builds, where debug info is rarely needed (backtraces for unittest crashes AFAICT). This can be also used to make LO itself run faster when developing, but I personally do not find it worth it (with Clang and full PCH this makes starmath build take about 70% longer, although presumably for non-PCH builds the relative increase will be smaller). Change-Id: I198d0759ebca94c90be662e02e0f1281a24d1d70 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88917 Reviewed-by: Michael Stahl <michael.stahl@cib.de> Reviewed-by: Luboš Luňák <l.lunak@collabora.com> Tested-by: Jenkins
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>
2020-02-10add BLOCK_PCH to gbuild, allowing partial non-PCH rebuildsLuboš Luňák
Both MSVC and Clang (with -building-pch-with-obj) generate one extra object file for code from the PCH, saving repeated generating of this code for every object using the PCH. This causes problems when temporarily disabling PCH by doing 'make ENABLE_PCH=' (e.g. when checking #include's are correct), as this object would no longer be linked in, and objects not rebuilt with PCH disabled would still need it. This patch allows doing 'make BLOCK_PCH=1' instead, which will disable PCH with the exception of this object file still getting linked in. Change-Id: I8fcb150ef27ebb34118d62739a1a1558aa1a6f3d Reviewed-on: https://gerrit.libreoffice.org/c/core/+/88341 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2020-01-18add support for Clang's -building-pch-with-objLuboš Luňák
This marks the PCH as having an accompanying object file, and this object file needs to be also built, but this allows the compiler to skip generating stuff that'd be shared by all the objects using the PCH. Currently it doesn't make much of a difference, few symbols if any, but template instantiations could be shared this way, as soon as Clang gets the necessary support (my WIP patch). Change-Id: Ib1b86338d85a47b48979558435253dc2672a0da8 Reviewed-on: https://gerrit.libreoffice.org/c/core/+/87009 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
2019-12-07Remove redundant gb_YACC indirectionStephan Bergmann
(as discussed at 0a803c0a41f46be4019ddd2768b4be5669b7ab59 "Honor BISON passed into configure") Change-Id: I160a3c97414be47cd1efef0b7fac4af93a398ac6 Reviewed-on: https://gerrit.libreoffice.org/84684 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-12-06Honor BISON passed into configureStephan Bergmann
...and require new-enough Bison for --enable-compiler-plugins to not generate bogus loplugin:external warnings in Bison boilerplate code. (As happend for me on macOS where /usr/bin/bison is version 2.3. Not sure which versions exactly are too old, but at least 3.4.1 is known good. If other versions newer than 2.3 turn out to be problematic too, the configure.ac check will need to be adapted.) No idea why there need to be three places across solenv/gbuild/ that set gb_YACC (to the same bison in each case), but leave that to be cleaned up later. Change-Id: I01d8219726f8df7895631b817866207327367759 Reviewed-on: https://gerrit.libreoffice.org/84650 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <sbergman@redhat.com>
2019-10-14fix incorrect gb_DISABLE_PCH_REUSE testLuboš Luňák
Change-Id: Ife41ea7ad19c03b8dca6afe8b15d0f3b752b533b Reviewed-on: https://gerrit.libreoffice.org/80789 Tested-by: Jenkins Reviewed-by: Luboš Luňák <l.lunak@collabora.com>
generated by cgit (git 2.34.1) at 2024-12-26 23:37:42 +0000