Build Failure on OpenSUSE Tumbleweed after distro upgrade: `NSSUTIL_3.59' not found

[Michael Stahl]

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.