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>
Java UNO Runtime (jurt)
JURT means Java UNO Runtime and implements most of Java UNO.