Bug 222625 – sys-devel/binutils-2.18.50.0.7 broken symbol versioning on solaris (causes dev-libs/nspr to fail)

• Product: Gentoo/Alt
• Status: RESOLVED FIXED

[Description Chí-Thanh Christopher Nguyễn 2008-05-18 12:16:05 UTC]

Under certain circumstances, ld from GNU binutils fails to correctly link versioned symbols.

Reproducible: Always

Steps to Reproduce:
1. emerge =sys-devel/binutils-2.18.50.0.7
2. emerge =dev-libs/nspr-4.7

Actual Results:  
sparc-sun-solaris2.10-gcc -shared -Wl,-h,libplds4.so,-z,combreloc,-z,defs,-z,ignore -o libplds4.so -Wl,--version-script,./pldsmap.sun -R '$ORIGIN' ./plarena.o ./plhash.o ./plvrsion.o   -L../../dist/lib -lnspr4 -lc
/home/pub/lib/gentoo-prefix/usr/lib/gcc/sparc-sun-solaris2.10/4.2.3/../../../../sparc-sun-solaris2.10/bin/ld: ../../dist/lib/libnspr4.so: open64: invalid version 28 (max 9)
../../dist/lib/libnspr4.so: could not read symbols: Bad value

Expected Results:  
Link correctly.

Building nspr with Sun's ld instead of GNU ld will succeed.
Other packages, like sys-devel/gcc with USE="gcj" fail with similar errors.

Related upstream bugs:
http://sourceware.org/bugzilla/show_bug.cgi?id=2524
http://sourceware.org/bugzilla/show_bug.cgi?id=6431

[Comment 1 Fabian Groffen 2008-05-18 20:04:10 UTC]

hard to fix, even the binutils guys seem to have no clue

[Comment 2 Markus Duft (RETIRED) 2008-05-19 06:46:17 UTC]

2.18.50 on solratis? What about the other 2.18 version? doesn't the .50 mean that there is linux specific stuff in there?

[Comment 3 Markus Duft (RETIRED) 2008-05-19 06:47:05 UTC]

(In reply to comment #2)
> 2.18.50 on solratis? What about the other 2.18 version? doesn't the .50 mean
> that there is linux specific stuff in there?

arghh... my keayboard again ;) of course i mean solaris, not solratis ;)

[Comment 4 Fabian Groffen 2008-05-19 08:09:08 UTC]

Given the upstream bugs, I don't think that matters at all for this bug.  I just know we had the problem with glib once, and haubi fixed it in some magical way.

[Comment 5 Chí-Thanh Christopher Nguyễn 2008-06-21 13:32:04 UTC]

Created attachment 157921 [details, diff]
nspr-4.7.1.ebuild.patch

Make nspr use Sun ld instead of GNU ld on sparc-solaris

[Comment 6 Michael Haubenwallner (RETIRED) 2008-06-23 12:05:05 UTC]

(In reply to comment #0)
> Steps to Reproduce:
> 1. emerge =sys-devel/binutils-2.18.50.0.7
> 2. emerge =dev-libs/nspr-4.7

Does it work with binutils-2.18 (any *.50 indeed is a Linux-release only) ?

Eventually we should drop any non-linux keyword from any binutils-*.50.

(In reply to comment #5)
> 
> Make nspr use Sun ld instead of GNU ld on sparc-solaris

Nice try, but this is definitely not the way to fix this ;)

[Comment 7 Fabian Groffen 2008-06-23 12:18:37 UTC]

(In reply to comment #6)
> (In reply to comment #0)
> > Steps to Reproduce:
> > 1. emerge =sys-devel/binutils-2.18.50.0.7
> > 2. emerge =dev-libs/nspr-4.7
> 
> Does it work with binutils-2.18 (any *.50 indeed is a Linux-release only) ?
> 
> Eventually we should drop any non-linux keyword from any binutils-*.50.

I've never found any problem yet with using them, and dropping the keywords so would end up in a maintenance nightmare.  If there is proof it breaks, please show.

> (In reply to comment #5)
> > 
> > Make nspr use Sun ld instead of GNU ld on sparc-solaris
> 
> Nice try, but this is definitely not the way to fix this ;)

I've been looking at the case.  In glib we had a similar problem that involved -lpthread that you solved by using -pthread instead to gcc.  Here I don't see that case, but I do see -lc, and maybe some of the other linked in libs are static, which seems to contribute to this bug.

[Comment 8 Fabian Groffen 2008-06-23 12:35:31 UTC]

I just edited pr/src/Makefile to use -pthread instead of -lphread on solaris and nspr completed compilation fine here.  I'll make the patch and try emerging from scratch.  But it looks quite hopeful since it's indirectly related to pthread again.

[Comment 9 Fabian Groffen 2008-06-23 12:47:01 UTC]

with my patch it compiles clean with an emerge, so it's left for haubi to enlighten us again on why this -lpthread/-pthread thing.  Fact seems to be that the compiler knows best in this case.

[Comment 10 Michael Haubenwallner (RETIRED) 2008-06-23 13:04:59 UTC]

Yes, try hard to let the compiler do its work (use -pthread instead of linking some obscure library here). It really should know best details like the required link order of libraries (libc+libpthread)...