Hide Forgot
Description of problem: When ldconfig is run during upgrading packages with dnf it complains about libnss3.s0 not being a symbolic link. Version-Release number of selected component (if applicable): nss-3.27.0-1.1.fc24.i686 rpm -qif /usr/lib/libnss3.so Name : nss Version : 3.27.0 Release : 1.1.fc24 Architecture: i686 Install Date: tor 06 okt 2016 05:28:14 CEST Group : System Environment/Libraries Size : 2380563 License : MPLv2.0 Signature : RSA/SHA256, man 03 okt 2016 06:54:57 CEST, Key ID 73bde98381b46521 Source RPM : nss-3.27.0-1.1.fc24.src.rpm Build Date : søn 02 okt 2016 21:48:52 CEST Build Host : buildvm-27.phx2.fedoraproject.org Relocations : (not relocatable) Packager : Fedora Project Vendor : Fedora Project URL : http://www.mozilla.org/projects/security/pki/nss/ Summary : Network Security Services Description : Network Security Services (NSS) is a set of libraries designed to support cross-platform development of security-enabled client and server applications. Applications built with NSS can support SSL v2 and v3, TLS, PKCS #5, PKCS #7, PKCS #11, PKCS #12, S/MIME, X.509 v3 certificates, and other security standards. How reproducible: Run dnf upgrade and notice output from ldconfig Or simply run ldconfig on Fedora 24 Steps to Reproduce: 1. 2. 3. Actual results: ldconfig: /usr/lib/libnss3.so is not a symbolic link Expected results: Should be empty Additional info: This problem has been seen in other releases, too.
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).