On 17/06/2021 11.24, Michael Stahl wrote:
On 12/06/2021 13.49, Jan-Marek Glogowski wrote:
Hi Luke,
Am 12.06.21 um 02:31 schrieb Luke Benes:
Builds are now failing on the rolling distro OpenSUSE Tumbleweed
After the latest update, both gcc and clang builds and both both
x86-64 and i686 architectures fail.
Seems to be caused by caused by:
java.io.IOException: /core/instdir/program/libnssutil3.so:
version `NSSUTIL_3.59' not found (required by /usr/lib64/libnss3.so)
mozilla-nss should provide libnss3.so(NSS_3.59)
https://opensuse.pkgs.org/tumbleweed/mozilla-x86_64/mozilla-nss-32bit-3.64-1.6.x86_64.rpm.html
Here is my upgrade log: https://controlc.com/79ec2502
Below is my build log.
If I add, "--with-system-nss" to my autogen.input file, the build
succeeds without any issue.
Any thoughts has to how to fix this or ideas on the root cause?
So the system lib /usr/lib64/libnss3.so, which is NSS 3.59, picks up
LO's own /core/instdir/program/libnssutil3.so, which is still at 3.55
for master...
Debugging that without an openSUSE system was a bit hard... IMHO this
is a bug in their java-11-openjdk source / java-11-openjdk-headless.
They provide a patched nss.cfg, on your system in
/usr/lib64/jvm/java-11-openjdk-11/conf/security/nss.cfg, which sets:
nssLibraryDirectory = /usr/lib64
My one on Debian doesn't.
The result is, that Java now always loads the libnss3.so from that
directory, instead of using the ld.so search order to find it (man
ld.so / man dlopen). But LO sets the LD_LIBRARY_PATH, so the ld.so
will first look for its libraries in /.../instdir/program. And there
it finds the libnssutil3.so from your build, which is too old and
misses the NSSUTIL_3.59 symbol, resulting in your error.
I suggest you try, if removing that line helps and then report a bug
to openSUSE.
uh... that sounds quite awful - did anybody report a bug about this?
actually i'm not sure how this can happen.
oosplash adds the output of "javaldx" to LD_LIBRARY_PATH but nothing
adds LO's program directory to it.
... 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.
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.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice
