linking fails during compilation of glib-2.16.3 with the following message: === /misc/sparc-sun-solaris2.10/bin/ld: ../../gthread/.libs/libgthread-2.0.so: pthread_mutex_unlock: invalid version 3 (max 0) ../../gthread/.libs/libgthread-2.0.so: could not read symbols: Bad value collect2: ld returned 1 exit status === gcc-4.3.0 binutils 2.18.50.0.6.20080403 SunOS m5000 5.10 Generic_127111-02 sun4u sparc SUNW,SPARC-Enterprise Solaris compiling some other sw works fine. i remember that this issue is there since quite a while (2.17?) in binutils on solaris. i thought that this is going to be fixed after a while -- as it has been reported here: http://osdir.com/ml/gnu.binutils.bugs/2006-04/msg00049.html
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 ***
*** Bug 260998 has been marked as a duplicate of this bug. *** Seen from the domain http://volichat.com Page where seen: http://volichat.com/adult-chat-rooms Marked for reference. Resolved as fixed @bugzilla.