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

Michael Stahl mst at
Thu Jun 17 09:41:07 UTC 2021

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:
>>> /core/instdir/program/ 
>>> version `NSSUTIL_3.59' not found (required by /usr/lib64/
>>> mozilla-nss should provide
>>> Here is my upgrade log:
>>> 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/, which is NSS 3.59, picks up 
>> LO's own /core/instdir/program/, 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 from that 
>> directory, instead of using the search order to find it (man 
>> / man dlopen). But LO sets the LD_LIBRARY_PATH, so the 
>> will first look for its libraries in /.../instdir/program. And there 
>> it finds the 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/ via 
nssLibraryDirectory, then some LO library is loaded that is linked to and finds program/ via RPATH, then JVM 
loads 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.

More information about the LibreOffice mailing list