Bug 6431

gcc was compiled to produce static versions of it's own libraries only.

will attach the gcc -v output of the glib link error.

Created attachment 2708 [details]
ld producing pthread_mutex_unlock: invalid version 3 (max 0)

similar error reported here:
http://osdir.com/ml/package-management.openpkg.user/2006-06/msg00046.html

... and here:
http://forums.mysql.com/read.php?11,199436,199436
http://lists.boost.org/boost-testing/2007/03/4242.php
http://mail.gnome.org/archives/gtk-list/2007-October/msg00145.html
http://mail.gnome.org/archives/gtk-devel-list/2007-July/msg00060.html
http://gcc.gnu.org/ml/gcc/2001-01/msg01468.html

I'm running into this problem, too (Solaris 10 11/06 s10x_u3wos_10 X86, ld
2.18), trying to build glib-2.15.4 with gcc 4.3.1.

still the same issue, using:
===
gcc-4.3.1
binutils-2.18.50.0.7.20080502
SunOS m5000-1.dev.nlatlu.wipro.com 5.10 Generic_127111-02 sun4u sparc
SUNW,SPARC-Enterprise Solaris
===

couple of other tests...
===
binutils-2.17.50.0.1: fails (like reported)
binutils-2.16.91.0.7: fails (like reported)
binutils-2.16.91.0.2: fails (like reported)
binutils-2.16.91.0.1: fails (different message)
binutils-2.16.90.0.3: fails (different message)
binutils-2.16.90.0.1: fails (different message)
binutils-2.15.94.0.2.2: fails (different message)
binutils-2.15.90.0.1: fails (different message)
binutils-2.14.90.0.1: fails (different message)
===
will attach this "different message".

Created attachment 2798 [details]
"different message"

same using 2.18.50.0.8.20080709

by the way, glib compiles file (same gcc/binutils) on:
===
SunOS e450-1.dev.nlatlu.wipro.com 5.8 Generic_117350-24 sun4u sparc SUNW,Ultra-4
Solaris
SunOS blade1000-2.dev.nlatlu.wipro.com 5.9 Generic_117171-12 sun4u sparc
SUNW,Sun-Blade-1000 Solaris
Linux amdlnx-1.newlogic.at 2.4.21-52.ELsmp #1 SMP Tue Sep 25 15:11:20 EDT 2007
x86_64 GNU/Linux
Linux pcxeon-1.newlogic.at 2.6.12-1.1381_FC3smp #1 SMP Fri Oct 21 04:03:26 EDT
2005 i686 GNU/Linux
===
so this bug seems to be related to changed from solaris9 -> solaris10 (in sparc
and x86)

file = fine

more details on the different platforms:

$ uname -s -m -r -p; nm  /lib/libpthread.so.0 | grep pthread_mutex_unlock
Linux 2.4.21-52.ELsmp x86_64 unknown
00007690 t __GI___pthread_mutex_unlock
00007690 T __pthread_mutex_unlock
00007690 T pthread_mutex_unlock

$ uname -s -m -r -p; nm  /lib/libpthread.so.0 | grep pthread_mutex_unlock
Linux 2.6.12-1.1381_FC3smp i686 unknown
00007530 t __GI___pthread_mutex_unlock
00007530 T __pthread_mutex_unlock
00007530 T pthread_mutex_unlock

$ uname -s -m -r -p; nm  /lib/libpthread.so.1 | grep pthread_mutex_unlock
SunOS 5.8 sun4u sparc
00003d84 T _pthread_mutex_unlock
00003d84 W pthread_mutex_unlock

$ uname -s -m -r -p; nm  /lib/libpthread.so.1 | grep pthread_mutex_unlock
SunOS 5.9 sun4u sparc
00003b8c T _pthread_mutex_unlock
00003b8c W pthread_mutex_unlock

$ uname -s -m -r -p; nm  /lib/libpthread.so.1 | grep pthread_mutex_unlock
SunOS 5.10 sun4u sparc
00000000 A _pthread_mutex_unlock
00000000 A pthread_mutex_unlock

found a workaround!!! ... it seems that on sol10, all pthread_XXX stuff is now
in libc.so. if you remove the -lpthread -thread options when glib compiles,
everything looks good.

for me (not a binutils/linker expert) it looks as /lib/libpthread.so.1 on
solaris10 only contains references, but /lib/libc.so.1 contains the real code:
===
$ nm /lib/libc.so.1 | grep pthread_mutex_unlock
000bdf98 W _pthread_mutex_unlock
000bdf98 W pthread_mutex_unlock
===
maybe ld should just skip those
===
$ nm  /lib/libpthread.so.1 | grep pthread_mutex_unlock
SunOS 5.10 sun4u sparc
00000000 A _pthread_mutex_unlock
00000000 A pthread_mutex_unlock
===
"empty" functions in /lib/libpthread.so.1 and check/use the other libraries ...

anyone out there who hack this is?

sorry, i meant: anyone out there who can hack this in?

Subject: Re:  ld says: invalid version 3 (max 0)

Hi niki,

> found a workaround!!! ... it seems that on sol10, all pthread_XXX stuff is now
> in libc.so. if you remove the -lpthread -thread options when glib compiles,
> everything looks good.

Hmm, so to me this sounds like it is a glib problem - ie its build 
makefile needs to be altered to remove the thread library when building 
on Solaris 10.  Have you tried asking about this on their email list ?

Cheers
   Nick

well -- as a workaround, you can remove -lpthread -thread options from gcc.

but binutils/ld should also be able to handle this case. exiting with a message
like "invalid version 3 (max 0)" is meaningless, especially, if it means that
you should remove some gcc options (and everything works ok, for some magic
reason) ...

the right way to fix this is binutils/ld, and not glib (and possibly every other
package using pthreads on solaris10).

(In reply to comment #13)
> found a workaround!!! ... it seems that on sol10, all pthread_XXX stuff is now
> in libc.so. if you remove the -lpthread -thread options when glib compiles,
> everything looks good.
> 
> for me (not a binutils/linker expert) it looks as /lib/libpthread.so.1 on
> solaris10 only contains references, but /lib/libc.so.1 contains the real code:
> ===
> $ nm /lib/libc.so.1 | grep pthread_mutex_unlock
> 000bdf98 W _pthread_mutex_unlock
> 000bdf98 W pthread_mutex_unlock
> ===
> maybe ld should just skip those
> ===
> $ nm  /lib/libpthread.so.1 | grep pthread_mutex_unlock
> SunOS 5.10 sun4u sparc
> 00000000 A _pthread_mutex_unlock
> 00000000 A pthread_mutex_unlock
> ===
> "empty" functions in /lib/libpthread.so.1 and check/use the other libraries ...
> 
> anyone out there who hack this is?

That doesn't really help if you are using glibc, in that case moving -lpthread
to the front does the trick.

The real problem is still there though.

This problem is not SPARC specific. I see it on i386-pc-solaris2.11.  I also
suspect that it is not Solaris specific either as it seems to be caused by
filter symbols not being interpreted correctly by binutils.

*** This bug has been marked as a duplicate of 2524 ***