Bug 1385260

My Fedora 24 x86_64 system doesn't show this error message when running ldconfig.

What does the following command show on your system?

  ls -l /usr/lib/libnss3*

It shows:

# ls -l /usr/lib/libnss3*
-rwxr-xr-x  1 root root 1276912  2 okt 20:55 /usr/lib/libnss3.so
-rwxr-xr-x. 1 root root 1273836  9 feb  2012 /usr/lib/libnss3.so_3.12
-rwxr-xr-x. 1 root root 1361324 27 okt  2013 /usr/lib/libnss3.so_3.15
-rwxr-xr-x  1 root root 1397944  8 maj  2014 /usr/lib/libnss3.so_3.16.1


The last 3 copies are copies I made myself for previous revisions of the library in order to solve this problem. At that time I made libnss3.so a symbolic link to one of the others. Looking at the RPM script it doesn't seem like such symbolic link is created during installation time.

Doing the same for the current version makes the error message from ldconfig disappear:

# ls -l libnss3.so*
lrwxrwxrwx  1 root root      17 18 okt 17:24 libnss3.so -> libnss3.so_3.27.0
-rwxr-xr-x. 1 root root 1273836  9 feb  2012 libnss3.so_3.12
-rwxr-xr-x. 1 root root 1361324 27 okt  2013 libnss3.so_3.15
-rwxr-xr-x  1 root root 1397944  8 maj  2014 libnss3.so_3.16.1
-rwxr-xr-x  1 root root 1276912  2 okt 20:55 libnss3.so_3.27.0
# ldconfig

The reason for the error is that you're using a modified configuration.

libnss3.so usually isn't a symbolic link, because NSS is supposed to be forward comaptible (old applications should work with newer NSS without rebuild).

I don't think this can be considered a bug in NSS.

OK. Removing the version based copies of libnss3.so gets rid of the error message.

With both files as regular files you get the error. 

]# ls -l libnss3*
-rwxr-xr-x 1 root root 1276912  2 okt 20:55 libnss3.so
-rwxr-xr-x 1 root root 1276912  2 okt 20:55 libnss3.so_3.27.0

Snippet from ldconfig -v
ldconfig: /usr/lib/libnss3.so is not a symbolic link

        libnss3.so -> libnss3.so_3.27.0

Removing libnss3.so leaving libnss3.so_3.27.0 and running ldconfig establishes the symbolic link:

# ldconfig
# ls -l libnss3*
lrwxrwxrwx 1 root root      17 18 okt 18:46 libnss3.so -> libnss3.so_3.27.0
-rwxr-xr-x 1 root root 1276912  2 okt 20:55 libnss3.so_3.27.0

(In reply to John Damm Sørensen from comment #2)
> The last 3 copies are copies I made myself for previous revisions of the
> library in order to solve this problem.

Does it mean that the problem occurred after just installing (or upgrading) the nss package without creating/removing any symbolic links manually?

Is the problem reproducible on a fresh installation of Fedora?

I haven't tried a fresh install. The current system is a result of numerous upgrades. But on a live DVD I get:

# ls -l /usr/lib/libnss3*
-rwxr-xr-x. 1 root root 1276928 Mar  8  2016 /usr/lib/libnss3.so

Here ldconfig doesn't complain.

I don't know the ldconfig logic for producing that warning, but given that it doesn't warn with the default configuration we ship, I don't think there's a bug in NSS.

This is about ldconfig behavior, so you could try to research if the ldconfig warning is justified or not.

Please read this and you will realize that your RPM doesn't conform to standards:
http://www.tldp.org/HOWTO/Program-Library-HOWTO/shared-libraries.html

Quote:
"3.1. Conventions

For shared libraries to support all of these desired properties, a number of conventions and guidelines must be followed. You need to understand the difference between a library's names, in particular its ``soname'' and ``real name'' (and how they interact). You also need to understand where they should be placed in the filesystem."

...

"Thus, /usr/lib/libreadline.so.3 is a fully-qualified soname, which ldconfig would set to be a symbolic link to some realname like /usr/lib/libreadline.so.3.0. There should also be a linker name, /usr/lib/libreadline.so which could be a symbolic link referring to /usr/lib/libreadline.so.3."

But NSS doesn't used versioned .so files, because of the compatibility promise, so I think that requirement doesn't apply to us (and ldconfig doesn't complain about our detault configuration).