Stephan Bergmann
c6302b4eda
...instead of using the default -static-libsan, where dynamic libraries must be built without -z defs and where all executables must link against the static libsan. Dropping the latter requirement means that we no longer need the static sal hack in Library_jpipe. But instead, at runtime, when a process loads any library that links against the dynamic libsan, then that dynamic libsan must be loaded first into the process. For executables that are themselves linked against the dynamic libsan, that is already the case. For scenarios where we invoke a Java executable, we now use LD_PRELOAD to fulfil that requirement. (And for invocation of Python executables, this commit assumes a --enable-python=fully-internal configuration, so that executable will be itself linked against the dynamic libsan.) Dropping the requirement to build without -z defs revealed that using -fsanitize=vptr often requires RTTI symbols from libraries that are not usually linked against. Such cases are now handled by conditionally including those libraries in gb_*_use_libraries calls. (This could be restricted even further to only be done under -shared-libsan, but it arguably doesn't hurt to also do it under the default -static-libsan.) The expectation is that -shared-libsan will explicitly be passed into the configuration along with any other -fsanitize... arguments via --with-extra-cc-flags and --with-extra-cxx-flags. This commit does not yet remove the code that is only needed for the (default) -static-libsan caes, but that code could eventually be cleaned up, once all (Clang) builds using sanitizers use -shared-libsan. (GCC already defaults to a shared model. Instead of a combined -shared-libsan, it has individual -shared-libasan etc., though. This commit does not intend to make any changes to any potential GCC sanitizer builds; my assumption is that we do not have any such, and that they wouldn't work out of the box, neither before nor after this change.) Change-Id: I932e4b75c299c158211e122adf33d7988892a87e Reviewed-on: https://gerrit.libreoffice.org/c/core/+/200935 Tested-by: Jenkins Reviewed-by: Stephan Bergmann <stephan.bergmann@collabora.com>
Tools and Non-Build Scripts
Tools and scripts mostly not used during the build
This direction has a number of key pieces (?) that are used during the
build, or are simply generally useful. One example is bin/run.
This utility can be used to run the executables in this folder:
workdir/LinkTarget/Executable
Format of the usage is:
./bin/run application [parameters]|--list|--help
Use --list (same as -list or -l) to get the list of executables Use --help (same as -help or -h) to get this help
Another example is:
bin/find-german-comments <directory>
which will try to detect and extract all the German comments in a
given source code hierarchy / directory.
Please note that the associated issue tdf#39468 is now marked as RESOLVED/FIXED, so don't expect many German comments.