Bug 313939 (MONO54694) - compilation failure (__tls_get_addr) [SOLUTION][GENTOO]
Summary: compilation failure (__tls_get_addr) [SOLUTION][GENTOO]
Status: RESOLVED MOVED
Alias: MONO54694
Product: Mono: Runtime
Classification: Mono
Component: misc (show other bugs)
Version: unspecified
Hardware: Other Linux
: P3 - Medium : Minor
Target Milestone: ---
Assignee: Mono Bugs
QA Contact: Mono Bugs
URL: http://www.diku.dk/hjemmesider/studer...
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2004-02-21 16:56 UTC by Zoltan Varga
Modified: 2007-09-15 21:24 UTC (History)
1 user (show)

See Also:
Found By: ---
Services Priority:
Business Priority:
Blocker: ---
Marketing QA Status: ---
IT Deployment: ---


Attachments
Test for loading shared libraries with TLS data (52 bytes, text/plain)
2004-02-21 21:48 UTC, Thomas Wiest
Details
Header file (20 bytes, text/plain)
2004-02-21 21:48 UTC, Thomas Wiest
Details
main() (44 bytes, text/plain)
2004-02-21 21:49 UTC, Thomas Wiest
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Thomas Wiest 2007-09-15 18:28:09 UTC


---- Reported by vargaz@freemail.hu 2004-02-21 09:56:06 MST ----

Some users reported compilation failures like this:

<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
/bin/sh ../../libtool --mode=link gcc  -g -O2 -fno-strict-aliasing -g
-Wall -Wunused -Wmissing-prototypes -Wmissing-declarations
-Wstrict-prototypes  -Wmissing-prototypes -Wnested-externs
-Wpointer-arith -Wno-cast-qual -Wcast-align -Wwrite-strings  -o mono
-export-dynamic main.o libmono.la                    -pthread
-lgthread-2.0 -lglib-2.0                       -Wl,--export-dynamic
-lgmodule-2.0 -ldl -lglib-2.0   -lm               -lpthread -lm
-L/usr/lib -licui18n -licuuc -licudata -lpthread -lm -lnsl -lpthread -lm
gcc -g -O2 -fno-strict-aliasing -g -Wall -Wunused -Wmissing-prototypes
-Wmissing-declarations -Wstrict-prototypes -Wmissing-prototypes
-Wnested-externs -Wpointer-arith -Wno-cast-qual -Wcast-align
-Wwrite-strings -o .libs/mono main.o -Wl,--export-dynamic
-Wl,--export-dynamic  ./.libs/libmono.so -L/usr/lib -pthread
/usr/lib/libgthread-2.0.so /usr/lib/libgmodule-2.0.so -ldl
/usr/lib/libglib-2.0.so -licui18n -licuuc -licudata -lnsl -lpthread -lm
-Wl,--rpath -Wl,/opt/mono//lib
./.libs/libmono.so: undefined reference to `___tls_get_addr'
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

This seems to be triggered by the usage of the __thread keyword in
runtime code. A workaround is to pass the --with-nptl=no option to 
configure.

Could somebody how encounters this problem produce a simple testcase ?
We could use the testcase to check for this problem in the configure
script.



---- Additional Comments From brunofr@olympum.com 2004-02-21 14:48:03 MST ----

Created an attachment (id=165646)
Test for loading shared libraries with TLS data




---- Additional Comments From brunofr@olympum.com 2004-02-21 14:48:33 MST ----

Created an attachment (id=165647)
Header file




---- Additional Comments From brunofr@olympum.com 2004-02-21 14:49:06 MST ----

Created an attachment (id=165648)
main()




---- Additional Comments From brunofr@olympum.com 2004-02-21 14:51:10 MST ----

gcc test.c -shared -o libtest.so
gcc testmain.c -L./ -ltest
./a.out: error while loading shared libraries: libtest.so: cannot
handle TLS data

[Note: Compiling without a shared library works ...
gcc test.c testmain.c -o test
./test  ... ok]




---- Additional Comments From lupus@ximian.com 2004-02-23 09:24:57 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO53525 has been marked as a duplicate of this bug. ***



---- Additional Comments From lupus@ximian.com 2004-02-23 09:31:33 MST ----

It looks like the build tools and the runtime on gentoo don't properly
support __thread in shared libraries. It's a bug in gentoo, people can
workaround it with --with-nptl=no as suggested by Zoltan.



---- Additional Comments From mtraudt@quantifisolutions.com 2004-03-25 08:20:59 MST ----

FYI, I experienced the same problem using Mandrake Linux 9.2.  The
suggested workaround seems to do the trick.



---- Additional Comments From vargaz@freemail.hu 2004-07-05 06:38:14 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO61111 has been marked as a duplicate of this bug. ***



---- Additional Comments From lupus@ximian.com 2004-07-06 06:16:19 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO61119 has been marked as a duplicate of this bug. ***



---- Additional Comments From vargaz@freemail.hu 2004-07-06 16:50:54 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO61197 has been marked as a duplicate of this bug. ***



---- Additional Comments From msolnit@istante.com 2004-07-14 18:48:50 MST ----

Would just like to note that this happened to me on RH9.0 as well 
(glibc-2.3.2-27.9.7).  configure option fixed it.



---- Additional Comments From mikko.korkalo@f-solutions.net 2004-07-15 14:35:22 MST ----

Happends on a fresh fedora core 2 installation too.



---- Additional Comments From mikko.korkalo@f-solutions.net 2004-07-15 14:37:49 MST ----

glibc-2.3.3-27 that is



---- Additional Comments From firefly@diku.dk 2004-07-17 19:18:14 MST ----

You probably have a "non-i686" CPU [*].

[this bug has been marked a duplicate of a bug that occurs with Fedora
and Ximian's prebuilt RPMs -- I also ran into it in that situation but
I think enough of my explanation will carry over to Gentoo for it to
be useful here.  I had a different, better version but Epiphany ate it
when it crashed :/]

This forces Fedora to not use its i686 version of the glibc package
and fall back to its i386 version.  The i386 version does not have
NPTL (Native Posix Threading Library) but uses LinuxThreads instead. 
Unfortunately, it doesn't support TLS (Thread-Local Storage) either. 
As far as I know, TLS doesn't require much support from libc apart
from asking the kernel to allocate some segments and loading the right
segment selector values into the GS register -- but maybe there is a
deep and good reason why TLS won't work with NPTL.

NPTL, the new threading support, doesn't work with the 386 because it
uses the CMPXCHG instruction for its internal spinlock implementation,
which doesn't exist on the 386.  There are other ways of coding this
in userspace -- or one could still use the CMPXCHG instruction and
have it emulated by the kernel.  This will work well as long as there
is only one 386 in the system (the 386 did not support SMP but Compaq
and possibly a few others built some machines with more than one 386
in them).

An other solution would be to have a glibc version compiled for the 486.

It is possible to take an SRPM for FC2 glibc, change the specfile
slightly, rebuild the RPM and install it.  This makes Ximian's
prebuilt Mono RPMs for FC2 work just fine on my Mobile Pentium MMX 233
MHz laptop :)  .... it did take 21h10m to build (and a week of
detective work!) and required about 2.1G disk space.

Anyway, the conclusion is that glibc is pre-broken in FC1 and FC2, at
least if you don't have the right CPU.

---

*: K6 and K6-2 are probably also considered non-i686 CPUs for the
purposes of this bug report.



---- Additional Comments From mikko.korkalo@f-solutions.net 2004-07-18 10:48:17 MST ----

Yes, the processor is P166 MMX (i586). Guess I should upgrade to a 
better testserver :)

Thanks for clearing this up.



---- Additional Comments From vargaz@freemail.hu 2004-07-22 19:05:05 MST ----

*** https://bugzilla.novell.com/show_bug.cgi?id=MONO61825 has been marked as a duplicate of this bug. ***



---- Additional Comments From bmaurer@users.sf.net 2004-08-27 18:01:59 MST ----

Duncan will disable nptl for 386s

*** This bug has been marked as a duplicate of https://bugzilla.novell.com/show_bug.cgi?id=MONO61119 ***

Imported an attachment (id=165646)
Imported an attachment (id=165647)
Imported an attachment (id=165648)

This bug was marked DUPLICATE in the database it was moved from.
    Changing resolution to "MOVED"