Basic system utils from /sbin and /bin cannot be linked against NSS from /usr/lib.
(For example /sbin/fsck.cramfs, /sbin/mkfs.cramfs where we use MD5 code.)
Please, move the library to /lib.
I assume this means we must move all NSS dependencies, too, to /lib
This includes NSPR
I have a patch to both packages that moves the files.
I built and installed locally, and I'm still able to run Firefox, even in FIPS
mode, which means moving the .chk files to /lib was ok, too.
The new listing of the packages is this:
[kaie@intel:~]$ rpm -ql nspr
[kaie@intel:~]$ rpm -ql nss
I'm now testing to build mozilla, to verify the system libs are still found in
that new location.
I'm reopening, because there are issues, thanks to Rob for making me aware.
NSS ships both .so files and .a files.
Before this change, all such files were located in the same directory, /usr/lib.
Now, after the change, we have the .so files in /lib and the .a files in /usr/lib.
Which of the following should be done?
(a) move all nss .a files to /lib
(b) change nss-config and pkg-config to list both /lib and /usr/lib
(c) - move only .so to /lib(64) and make symlink in /usr/lib(64) pointing to
/lib(64), leave nss-config and pkg-config as is.
I think this is the most correct way.
which .a files?
I'm starting to think we need multiple results from pkg-config.
1) applications that just use crypto & certificates (-lnss3 -lnss3util -lsoftoken3)
2) applications that just use ssl (-lssl3 -lnss3 -lnss3util -lsoftoken3 )
3) applications that just use smime (-lsmime3 -lnss3 -lnss3util -lsoftoken3)
4) applications that all shared libraries (-lssl3 -lsmime3 -lnss3 -lnss3util
5) applications that use various nss .a files.
Default would be 4). 5 would include both /lib and /usr/lib. 5 may be split up
wrt which .a files are included.
I don't think we want to include the nss .a files in /lib.
Bob, Tomas, thanks a lot for your quick replies.
(In reply to comment #5)
> (c) - move only .so to /lib(64) and make symlink in /usr/lib(64) pointing to
> /lib(64), leave nss-config and pkg-config as is.
I like this proposal.
I think you want that nss-config and pkg-config point to /usr/lib(64).
(they currently point to /lib(64))
(In reply to comment #6)
> which .a files?
nss-devel has libcrmf.a and
nss-pkcs11-devel has libnssb.a and libbssckfw.a
> I'm starting to think we need multiple results from pkg-config.
This sounds complicated.
I think this proposal will not work as soon as you have an application that
wants to link with both .so files and a .a file (like PSM).
> I don't think we want to include the nss .a files in /lib.
Bob, do you think Thomas's proposal is good?
I found that "zlib" and "zlib-devel" already implement what Tomas proposes.
$ rpm -ql zlib| grep -w so | xargs ls -ld
lrwxrwxrwx 1 root root 13 13. Jan 04:50 /lib/libz.so.1 -> libz.so.1.2.3
-rwxr-xr-x 1 root root 74928 15. Aug 2007 /lib/libz.so.1.2.3
$ rpm -ql zlib-devel| grep -w so | xargs ls -ld
lrwxrwxrwx 1 root root 23 13. Jan 04:51 /usr/lib/libz.so -> ../../lib/libz.so.1.2.3
> Bob, do you think Thomas's proposal is good?
> nss-devel has libcrmf.a
The users of libcrmf.a are pretty small. It would be safe
> nss-pkcs11-devel has libnssb.a and libbssckfw.a
nss-pkcs11-devel should have it's own pkg-config. Applications that use these
will not like with any of the NSS shared libraries.
> This sounds complicated.
> I think this proposal will not work as soon as you have an application that
> wants to link with both .so files and a .a file (like PSM).
I'm particularly interest in those packages that just need nss3 or just need
There is a hierarchy, so it's not as complicated as it sounds. For instance, all
users of libcrmf.a would automatically need the rest of NSS (at least nss3 and
smime3) anyway. In that case I would say 5) would be include all the libraries.
If we included some of the libraries used for nss-tools, they should probably
include their own pkg-config...
(In reply to comment #7)
> I like this proposal.
> I think you want that nss-config and pkg-config point to /usr/lib(64).
> (they currently point to /lib(64))
Adding Chris and Martin to make sure you're aware of this change in rawhide. If
something goes wrong, please let me know. Ideally you won't notice the change.
I hope they are in the buildroot already, maybe it'll take another hour or so.
Rob, could you please try if this works for you?
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
builds as of 2008-07-03, version 188.8.131.52-3.fc10.