On 17.06.21 12:54, Stephan Bergmann wrote:
On 17/06/2021 11:41, Michael Stahl wrote:
... perhaps like this: first JVM loads /usr/lib64/libnss3.so via
nssLibraryDirectory, then some LO library is loaded that is linked to
libnss3util.so and finds program/libnssutil3.so via RPATH, then JVM
loads libnss3util.so but since a shared object with that name is
already loaded it's a no-op.
...or, more likely, first some LO library caused the LO
program/libnss3util.so to be loaded, and then the JVM loaded
/usr/lib64/libnss3.so, which likely has a DT_NEEDED of libnss3util.so
(at least my nss-3.65.0-1.fc34.x86_64 does) and, as you already
concluded, happily picks up the wrong, already loaded
program/libnss3util.so
oh yes indeed i mixed up what depends on what...
maybe we should think about defaulting to --with-system-nss on Linux, particularly for release builds; there hasn't been a reason to bundle it in 5 years or so.
here is a patch to do that:
https://gerrit.libreoffice.org/c/core/+/120388
