Description of problem: nss-tools-3.11.2-1.i386.rpm /usr/bin/certutil RPATH $ORIGIN/../lib /usr/bin/modutil RPATH $ORIGIN/../lib /usr/bin/pk12util RPATH $ORIGIN/../lib /usr/bin/ssltap RPATH $ORIGIN/../lib Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
The rpath option is new to me, but you seem to complain it is being used by NSS tools, and I assume you request it should not be used. Looking at source file mozilla/security/nss/cmd/platlibs.mk I found the following comment: # If GNU ld is used, we must use the -rpath-link option to tell # the linker where to find libsoftokn3.so, an implicit dependency # of libnss3.so.
Florian, we only use rpath with the $ORIGIN linker keyword. Should we still avoid this usage? Kai, the relevant makefile code is the following in mozilla/security/nss/cmd/platlibs.mk: ifeq ($(OS_ARCH), Linux) ifeq ($(USE_64), 1) EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib64:$$ORIGIN/../lib' else EXTRA_SHARED_LIBS += -Wl,-rpath,'$$ORIGIN/../lib' endif endif If required by the policy of our distributions, we can add a patch to the NSS RPM to remove the above makefile code. The rpath option is useful when the NSS libraries are not installed in the system lib directory.
We don't have a requirement to clean this up and AFAIK it is no show-stopper for a release, but most packages try to avoid rpath and anyway install into system paths. I'd just remove the above lines for the Red Hat rpm packages. regards, Florian La Roche
I plan to disable rpath in the devel version of nss with the upcoming next nss release.
fixed in rawhide