I don't really know if this is a bug at all. But I've my own revdev-rebuild script ( http://svn.xmw.de/gentoo-gaf/de.xmw.m.pandora/usr/local/sbin/revdep-mw.py ) and it warns: about missing library libnss3.so in the files /usr/lib32/nss/libsmime3.so.12 and /usr/lib32/nss/libssl3.so.12 of app-emulation/emul-linux-x86-baselibs-20100220 revdep-rebuild does not. pandora gdm # ldd /usr/lib32/nss/libssl3.so.12 /usr/lib32/nss/libsmime3.so.12 /usr/lib32/nss/libssl3.so.12: linux-gate.so.1 => (0xf7779000) libz.so.1 => /lib32/libz.so.1 (0xf7702000) libnss3.so => not found libnssutil3.so => not found libplc4.so.8 => not found libnspr4.so.8 => not found libpthread.so.0 => /lib32/libpthread.so.0 (0xf76e8000) libc.so.6 => /lib32/libc.so.6 (0xf75a2000) /lib/ld-linux.so.2 (0xf777a000) /usr/lib32/nss/libsmime3.so.12: linux-gate.so.1 => (0xf7797000) libnss3.so => not found libnssutil3.so => not found libplc4.so.8 => not found libnspr4.so.8 => not found libc.so.6 => /lib32/libc.so.6 (0xf75f9000) /lib/ld-linux.so.2 (0xf7798000) I've discovered this examining an env.d file of adobe-flash ( http://bugs.gentoo.org/show_bug.cgi?id=311575 ). Adding LDPATH=/usr/lib32/nss:/usr/lib32/nspr into a new env.d file and env-update solves this. pandora gdm # ldd /usr/lib32/nss/libssl3.so.12 /usr/lib32/nss/libsmime3.so.12 /usr/lib32/nss/libssl3.so.12: linux-gate.so.1 => (0xf7715000) libz.so.1 => /lib32/libz.so.1 (0xf769e000) libnss3.so => /usr/lib32/nss/libnss3.so (0xf758f000) libnssutil3.so => /usr/lib32/nss/libnssutil3.so (0xf7576000) libplc4.so.8 => /usr/lib32/nspr/libplc4.so.8 (0xf7571000) libnspr4.so.8 => /usr/lib32/nspr/libnspr4.so.8 (0xf753c000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf7523000) libc.so.6 => /lib32/libc.so.6 (0xf73dd000) libplds4.so.8 => /usr/lib32/nspr/libplds4.so.8 (0xf73d9000) libdl.so.2 => /lib32/libdl.so.2 (0xf73d5000) /lib/ld-linux.so.2 (0xf7716000) /usr/lib32/nss/libsmime3.so.12: linux-gate.so.1 => (0xf7715000) libnss3.so => /usr/lib32/nss/libnss3.so (0xf75af000) libnssutil3.so => /usr/lib32/nss/libnssutil3.so (0xf7596000) libplc4.so.8 => /usr/lib32/nspr/libplc4.so.8 (0xf7591000) libnspr4.so.8 => /usr/lib32/nspr/libnspr4.so.8 (0xf755d000) libc.so.6 => /lib32/libc.so.6 (0xf7416000) libplds4.so.8 => /usr/lib32/nspr/libplds4.so.8 (0xf7412000) libpthread.so.0 => /lib32/libpthread.so.0 (0xf73f9000) libdl.so.2 => /lib32/libdl.so.2 (0xf73f5000) /lib/ld-linux.so.2 (0xf7716000) ldd ... equals LD_TRACE_LOADED_OBJECTS=1 /lib/ld-linux.so.2 ... for ELFA files. Is this only a theoretical problem or could it lead to segfaults at nss/nspr calls? Michael
that's odd, wonder why they are in the subdir... app-emulation/emul-linux-x86-baselibs (/usr/lib32/nss/libsmime3.so) dev-libs/nss (/usr/lib64/libsmime3.so) app-emulation/emul-linux-x86-baselibs (/usr/lib32/nspr/libnspr4.so) dev-libs/nspr (/usr/lib64/libnspr4.so)
(In reply to comment #1) > that's odd, wonder why they are in the subdir... > > app-emulation/emul-linux-x86-baselibs (/usr/lib32/nss/libsmime3.so) > dev-libs/nss (/usr/lib64/libsmime3.so) > app-emulation/emul-linux-x86-baselibs (/usr/lib32/nspr/libnspr4.so) > dev-libs/nspr (/usr/lib64/libnspr4.so) > Even dev-libs/nspr and dev-libs/nss install them in a subdir in my case, maybe we have different installed versions: dev-libs/nspr-4.8 dev-libs/nss-3.12.5
Seems that it was changed in *nss-3.12.5-r1 (11 Feb 2010) 11 Feb 2010; <anarchy@gentoo.org> +nss-3.12.5-r1.ebuild: Address concerns from upstream about our build, move to /usr/lib{64}
(In reply to comment #3) > Seems that it was changed in > > *nss-3.12.5-r1 (11 Feb 2010) > > 11 Feb 2010; <anarchy@gentoo.org> +nss-3.12.5-r1.ebuild: > Address concerns from upstream about our build, move to /usr/lib{64} > Mozilla team, when will new nss/nspr be ready to go stable? Thanks
The libs belong in /usr/lib32. lib32 layout shouldn't be any different from lib(64).
Should be fixed in 20100409 Thanks for reporting
