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>
Contains the Network Security Services (NSS) libraries from Mozilla == ESR versions == Upstream releases both regular and "ESR" versions, the latter go into Firefox ESR and Thunderbird. There is a new ESR version about once a year, and a ESR version gets micro updates only when there are security issues to fix, and it's not always obvious from the release notes of a regular release if there are security issues that are relevant to LibreOffice, hence it's probably best to bundle only the ESR versions and upgrade for every micro release (as recommended by upstream). == Fips 140 and signed libraries == Fips 140 mode is not supported. That is, the *.chk files containing the checksums for the cryptographic module are not delivered into instdir and will not be part of the OOo installation sets. Signing has been turned off because - we change the rpath (install names) after signing which breaks the signatures (Mac) - sqlite conflicts with the system sqlite when signing which breaks the build See also [https://developer.mozilla.org/en-US/docs/Mozilla/Projects/NSS/NSS_Tech_Notes/nss_tech_note6] == libsqlite3 == With all supported macOS SDK we use NSS_USE_SYSTEM_SQLITE=1 to build using the system sqlite.