Fix runtime on OpenBSD after bug 1036894 (missing SONAME tag in nspr/ldap-sdks libs)

RESOLVED FIXED in mozilla37

Status

RESOLVED FIXED
4 years ago
6 months ago

People

(Reporter: gaston, Assigned: gaston)

Tracking

34 Branch
mozilla37
x86_64
OpenBSD

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Assignee)

Description

4 years ago
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 ?
(Assignee)

Comment 1

4 years ago
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
(Assignee)

Updated

4 years ago
Blocks: 1036894
(Assignee)

Comment 2

4 years ago
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
(Assignee)

Comment 3

4 years ago
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.
(Assignee)

Comment 4

4 years ago
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...
(Assignee)

Comment 5

4 years ago
Created attachment 8532889 [details] [diff] [review]
Link nspr libs with -soname on OpenBSD (nspr patch)

Linking nspr libs using -Wl,-soname indeed fixes the issue, no need to hack our ld. Patch for projects/nspr repo.
Assignee: nobody → landry
Attachment #8532889 - Flags: review?(wtc)
(Assignee)

Comment 6

4 years ago
Created attachment 8532890 [details] [diff] [review]
Link nspr libs with -soname on OpenBSD (m-i patch)

Same patch for m-i, if it can land separately or *has* to go to nspr first and then get merged to m-i.....
Attachment #8532890 - Flags: review?(mh+mozilla)
(Assignee)

Comment 7

4 years ago
Created attachment 8532891 [details] [diff] [review]
Link ldap libs with -soname on OpenBSD (ldap/sdks patch)

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.
Attachment #8532891 - Flags: review?(standard8)
Attachment #8532891 - Flags: feedback?(Pidgeot18)
(Assignee)

Updated

4 years ago
Summary: strange relative paths for dependencies in linked libraries → Fix runtime on OpenBSD after bug 1036894 (missing SONAME tag in nspr/ldap-sdks libs)
(Assignee)

Updated

4 years ago
Attachment #8532889 - Flags: review?(ted)
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.
Attachment #8532890 - Flags: review?(mh+mozilla)
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.
Attachment #8532891 - Flags: review?(standard8)
Attachment #8532891 - Flags: feedback?(Pidgeot18)
(Assignee)

Comment 10

4 years ago
(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...)
(Assignee)

Comment 11

4 years ago
Fwiw, these patches allows my buildbot to be green again after a long period of burning.. http://buildbot.rhaalovely.net/one_line_per_build
Attachment #8532889 - Flags: review?(wtc)
Attachment #8532889 - Flags: review?(ted)
Attachment #8532889 - Flags: review+
http://hg.mozilla.org/projects/nspr/rev/91625f36dc69
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → FIXED
(Assignee)

Updated

4 years ago
Attachment #8532891 - Flags: review?(standard8)
(Assignee)

Comment 13

4 years ago
Will mark as actually resolved fixed when m-c *and* c-c build & run fine unpatched...
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attachment #8532891 - Flags: review?(standard8) → review+
https://hg.mozilla.org/comm-central/rev/2522b98e9bfd
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla37
(Assignee)

Comment 16

4 years ago
Leaving open until m-c builds fine unpatched - ie until nspr 4.8.something is lifted up.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---

Comment 17

4 years ago
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.
Attachment #8532889 - Flags: review+

Updated

4 years ago
Keywords: leave-open

Updated

4 years ago
Blocks: 1112904

Updated

4 years ago
No longer blocks: 1112904
See Also: → bug 1112904
(Assignee)

Comment 18

4 years ago
Are there any plans to update nspr in m-c ?
Flags: needinfo?(ted)
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.
Flags: needinfo?(ted)
(Assignee)

Comment 20

4 years ago
all i need is http://hg.mozilla.org/projects/nspr/rev/91625f36dc69 to reach m-c someday.....
(Assignee)

Comment 21

4 years ago
Was merged in m-c in bug 1119469, closing now.
Status: REOPENED → RESOLVED
Last Resolved: 4 years ago4 years ago
Resolution: --- → FIXED
Removing leave-open keyword from resolved bugs, per :sylvestre.
Keywords: leave-open

Updated

6 months ago
Product: Core → Firefox Build System
You need to log in before you can comment on or make changes to this bug.