Hello, GNU Guile relies on TLS (thread-local storage) support where available, and can live without it on inferior systems. However, I haven’t found a reliable way to check whether TLS is supported.
Initially, TLS support was tested with: AC_LINK_IFELSE([AC_LANG_PROGRAM([__thread int tls_integer;], [tls_integer = 123;])], [ac_cv_have_thread_storage_class="yes"], [ac_cv_have_thread_storage_class="no"]) But this isn’t enough since some systems (e.g., x86_64-unknown-netbsd5.0. and sparc-sun-solaris2.8) would both successfully link a program but fail to create a shared library, or fail to link a program against a shared library that uses TLS. The examples below are with these files: --8<---------------cut here---------------start------------->8--- $ cat foo.c __thread int foo; int bar(void){ return foo; } $ cat main.c int main () { return bar(); } --8<---------------cut here---------------end--------------->8--- Case #0: --8<---------------cut here---------------start------------->8--- $ ./config.guess sparc-sun-solaris2.8 $ /opt/csw/gcc3/bin/gcc --version gcc (GCC) 3.4.6 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /opt/csw/gcc3/bin/gcc -shared -o libfoo.so foo.c foo.c:1: error: thread-local storage not supported for this target --8<---------------cut here---------------end--------------->8--- Case #1: --8<---------------cut here---------------start------------->8--- $ ./config.guess sparc-sun-solaris2.8 $ /opt/csw/gcc4/bin/gcc --version gcc (GCC) 4.3.3 Copyright (C) 2008 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. $ /opt/csw/gcc4/bin/gcc -shared -o libfoo.so foo.c Text relocation remains referenced against symbol offset in file __emutls_v.foo 0x4 /var/tmp//ccCCHRQO.o __emutls_v.foo 0x8 /var/tmp//ccCCHRQO.o __emutls_get_address 0xc /var/tmp//ccCCHRQO.o ld: fatal: relocations remain against allocatable but non-writable sections --8<---------------cut here---------------end--------------->8--- Likewise on NetBSD 5.0: --8<---------------cut here---------------start------------->8--- creating libguile-2.0.la (cd .libs && rm -f libguile-2.0.la && ln -s ../libguile-2.0.la libguile-2.0.la) gcc -std=gnu99 -DHAVE_CONFIG_H -DBUILDING_LIBGUILE=1 -I.. -I.. -I../lib -I../lib -I/usr/pkg/include -I/usr/pkg/include -I/usr/y0/include -I/usr/pkg/include -I/usr/y0/include -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -fvisibility=hidden -I/usr/pkg/include -g -O2 -MT guile-guile.o -MD -MP -MF .deps/guile-guile.Tpo -c -o guile-guile.o `test -f 'guile.c' || echo './'`guile.c mv -f .deps/guile-guile.Tpo .deps/guile-guile.Po /bin/ksh ../libtool --tag=CC --mode=link gcc -std=gnu99 -I/usr/pkg/include -I/usr/y0/include -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -fvisibility=hidden -I/usr/pkg/include -g -O2 -I/usr/pkg/include -I/usr/y0/include -L/usr/pkg/lib -R/usr/pkg/lib -L/usr/y0/lib -R/usr/y0/lib -o guile guile-guile.o libguile-2.0.la -L/usr/pkg/lib -lgc -L/usr/y0/lib -lunistring -R/usr/y0/lib -lcrypt -lm -lltdl gcc -std=gnu99 -I/usr/pkg/include -I/usr/y0/include -Wall -Wmissing-prototypes -Wdeclaration-after-statement -Wundef -Wswitch-enum -fvisibility=hidden -I/usr/pkg/include -g -O2 -I/usr/pkg/include -I/usr/y0/include -o .libs/guile guile-guile.o -L/usr/pkg/lib -L/usr/y0/lib ./.libs/libguile-2.0.so /usr/pkg/lib/libffi.so /usr/pkg/lib/libgmp.so /usr/pkg/lib/libintl.so -lc /usr/pkg/lib/libgc.so -lpthread -lrt /usr/y0/lib/libunistring.so -lcrypt -lm /usr/pkg/lib/libltdl.so -Wl,--rpath -Wl,/usr/local/lib -Wl,--rpath -Wl,/usr/pkg/lib -Wl,--rpath -Wl,/usr/y0/lib ./.libs/libguile-2.0.so: warning: warning: tmpnam() possibly used unsafely, use mkstemp() or mkdtemp() ./.libs/libguile-2.0.so: undefined reference to `__tls_get_addr' --8<---------------cut here---------------end--------------->8--- (From <http://autobuild.josefsson.org/guile/log-201005301005665537000.txt>. The discussion at <http://lists.gnu.org/archive/html/guile-devel/2009-10/msg00189.html> has additional details.) Case #2: --8<---------------cut here---------------start------------->8--- $ ./config.guess sparc-sun-solaris2.8 $ /opt/studio/SOS11/SUNWspro/bin/cc -V cc: Sun C 5.8 Patch 121015-07 2009/04/22 usage: cc [ options] files. Use 'cc -flags' for details $ /opt/studio/SOS11/SUNWspro/bin/cc -G -h libfoo.so foo.c $ mv a.out libfoo.so $ /opt/studio/SOS11/SUNWspro/bin/cc main.c ./libfoo.so --8<---------------cut here---------------end--------------->8--- So it seems that the right test, when compiling natively, involves building a shared library and an executable linked against it, and running that executable. That’s where you come in. ;-) How can libtool’s knowledge of compilers and linkers be leveraged from ‘configure’ to write such a test? Thanks, Ludo’. _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool