Since a while my buildbot fails to run xpcshell, see for example: http://buildbot.rhaalovely.net/builders/mozilla-central-amd64/builds/1312/steps/package/logs/stdio Executing /usr/obj/buildslave/m-c/dist/bin/xpcshell -g /usr/obj/buildslave/m-c/dist/bin/ -a /usr/obj/buildslave/m-c/dist/bin/ -f /var/buildslave-mozilla/mozilla-central-amd64/build/toolkit/mozapps/installer/precompile_cache.js -e precompile_startupcache("resource://gre/"); /usr/obj/buildslave/m-c/dist/bin/xpcshell: can't load library '../../../nsprpub/lib/libc/src/libplc4.so.1.0' objdump -p on the binary shows that NEEDED lines have relative paths to depending libs, and those relative paths point nowhere. While building seamonkey 2.31b2, i've noticed the same broken thing: objdump -p /usr/local/lib/seamonkey-2.31/libxul.so.40.0 NEEDED ../../ldap/sdks/c-sdk/ldap/libraries/libldap/libldap60.so.40.0 NEEDED ../../ldap/sdks/c-sdk/ldap/libraries/libldif/libldif60.so.40.0 NEEDED ../../ldap/sdks/c-sdk/ldap/libraries/libprldap/libprldap60.so.40.0 Those libs are present in the same dir as libxul.so.40.0, so there should be no need for a relative path here... the fact that it happens for seamonkey 2.31 lets me believe this is a change that went in the 34 branch. No issue with TB 31.3.0 ESR, or FX 34.0 when building with system nspr/nss. Bug 1036832 is in that timeframe and related to linking, but i doubt that's it... Mike, any idea ?

Here's what i get on a freshly build xpcshell : $objdump -p /usr/obj/m-c/dist/bin/xpcshell | grep NEEDED NEEDED libmozalloc.so.1.0 NEEDED ../../../nsprpub/lib/ds/libplds4.so.1.0 NEEDED ../../../nsprpub/lib/libc/src/libplc4.so.1.0 NEEDED ../../../nsprpub/pr/src/libnspr4.so.1.0 NEEDED libxul.so.1.0 NEEDED libstdc++.so.57.0 NEEDED libm.so.9.0 NEEDED libpthread.so.18.0 NEEDED libc.so.77.0

So, after some digging, it looks to be a "special behaviour" of our ld 2.15, which when given relative paths to .so, registers them with the relative path in the NEEDED field instead of only the soname without path, as it is done for example with ld 2.18 on debian squeeze. devel:/tmp/ #echo 'int main() { return 0 ; }' > t.c devel:/tmp/ #cc -lgeos -o t t.c devel:/tmp/ #objdump -p t | grep NEEDED NEEDED libgeos-3.0.0.so NEEDED libc.so.6 devel:/tmp/ #ld -v GNU ld (GNU Binutils for Debian) 2.18.0.20080103 devel:/tmp/ #rm t devel:/tmp/ #cc ../usr/lib/libgeos.so -o t t.c devel:/tmp/ #objdump -p t | grep NEEDED NEEDED libgeos-3.0.0.so NEEDED libc.so.6 twilight:~/ $ld -v GNU ld version 2.15 twilight:~/ $echo 'int main() { return 0 ; }' > t.c twilight:~/ $LDFLAGS=-lkvm make t cc -O2 -pipe -lkvm -o t t.c twilight:~/ $objdump -p t | grep NEED NEEDED libkvm.so.16.0 NEEDED libc.so.77.0 twilight:~/ $rm t twilight:~/ $LDFLAGS=../../usr/lib/libkvm.so.16.0 make t cc -O2 -pipe ../../usr/lib/libkvm.so.16.0 -o t t.c twilight:~/ $objdump -p t | grep NEED NEEDED ../../usr/lib/libkvm.so.16.0 NEEDED libc.so.77.0

Digging a bit more, GNU ld 2.17.50 [FreeBSD] 2007-07-03 and GNU ld (NetBSD Binutils nb1) 2.21.1 have the same behaviour as linux'. It seems to be specific to the way our ld is configured.... From that point, two options : - fix our ld (has been tried before, went nowhere) - specialcase the changes from bug 1036894 for OpenBSD's ld 2.15. argh ? - locally patch the thing to use something else than EXTRA_LIBS for libs coming from the mozilla tree (to be tried) - but that basically breaks my buildbot forever.

And after being explained how that stuff was supposed to work, it's not a specificity of our ld, it seems caused by the fact that nspr libs arent linked with a soname, as ldap libs. nss libs have a soname, and thus binaries linked against them dont exhibit that issue. Our basesystem libraries have no soname either, explaining why libkvm would be linked with its full path. Guess now i'll dig into ldap and nspr makefiles to figure out why we dont link them with a soname, and the historical reasons for it...

Linking nspr libs using -Wl,-soname indeed fixes the issue, no need to hack our ld. Patch for projects/nspr repo.

Same patch for m-i, if it can land separately or *has* to go to nspr first and then get merged to m-i.....

Link ldap libs with -soname on OpenBSD, fixes seamonkey 2.31 startup. Of course this also needs a ldap-sdks repo tag (LDAPCSDK_6_0_7G_RTM ?) + client.py patch to pull from it.

Comment on attachment 8532890 [details] [diff] [review] Link nspr libs with -soname on OpenBSD (m-i patch) Review of attachment 8532890 [details] [diff] [review]: ----------------------------------------------------------------- As annoying as it is, it's better to get a plain nspr tag in the tree than to patch it in-tree.

Comment on attachment 8532891 [details] [diff] [review] Link ldap libs with -soname on OpenBSD (ldap/sdks patch) Please get review on the m-c/nspr patches first.

(In reply to Mark Banner (:standard8) from comment #9) > Comment on attachment 8532891 [details] [diff] [review] > Link ldap libs with -soname on OpenBSD (ldap/sdks patch) > > Please get review on the m-c/nspr patches first. Why ? they're independent from the ldap libs patch.. which i'm shipping to fix runtime in seamonkey 2.31 (it doesnt have the issue on nspr, since i link against systemwide nspr...)

Fwiw, these patches allows my buildbot to be green again after a long period of burning.. http://buildbot.rhaalovely.net/one_line_per_build

Will mark as actually resolved fixed when m-c *and* c-c build & run fine unpatched...

Leaving open until m-c builds fine unpatched - ie until nspr 4.8.something is lifted up.

Comment on attachment 8532889 [details] [diff] [review] Link nspr libs with -soname on OpenBSD (nspr patch) Review of attachment 8532889 [details] [diff] [review]: ----------------------------------------------------------------- r=wtc. ::: configure.in @@ +2177,5 @@ > OS_LIBS="-lc" > if test -z "$USE_NSPR_THREADS"; then > USE_PTHREADS=1 > fi > + DSO_LDOPTS='-shared -fPIC -Wl,-soname,$(notdir $@)' We use -Wl,-soname -Wl,$(notdir $@) on other platforms. We should standardize on the more compact form used in this patch.

Are there any plans to update nspr in m-c ?

We generally update the m-c copy as-needed. If all the patches you need have landed in the NSPR repo I can tag a new beta and someone can push it.

all i need is http://hg.mozilla.org/projects/nspr/rev/91625f36dc69 to reach m-c someday.....

Was merged in m-c in bug 1119469, closing now.

Removing leave-open keyword from resolved bugs, per :sylvestre.