reference to ___tls_get_addr

Hi,
I'm trying to compile code that use threads; and link fails
with an
undefined reference to ___tls_get_addr:
gcc -O2 -I/usr/pkg/include/python2.4 -I/usr/include
-I/usr/pkg/include -m32 -march=i686 -DNDEBUG -std=gnu99
-Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement  -D__XEN_TOOLS__ 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-mno-tls-direct-seg-refs -m32 -march=i686 -DNDEBUG
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement  -D__XEN_TOOLS__ 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-mno-tls-direct-seg-refs -Werror -Wp,-MD,.xenstored.d 
-I../../tools/libxc -I. -L/usr/pkg/lib/python2.4/config
-Wl,-R/usr/pkg/lib/python2.4/config -L/usr/lib
-Wl,-R/usr/lib -L/usr/pkg/lib -Wl,-R/usr/pkg/lib       
-L../../tools/libxc xenstored_core.o xenstored_watch.o
xenstored_domain.o xenstored_transaction.o xs_lib.o talloc.o
utils.o tdb.o hashtable.o xenstored_netbsd.o   -lxenctrl  -o
xenstored
../../tools/libxc/libxenctrl.so: undefined reference to
`___tls_get_addr'

I'm almost sure that it's gcc which generates this
reference, I didn't find
it in any source. It comes from a file built like that:
gcc -I/usr/pkg/include/python2.4 -I/usr/include
-I/usr/pkg/include -DPIC -O2 -I/usr/pkg/include/python2.4
-I/usr/include -I/usr/pkg/include -m32 -march=i686 -DNDEBUG
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement  -D__XEN_TOOLS__ 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-mno-tls-direct-seg-refs -m32 -march=i686 -DNDEBUG
-std=gnu99 -Wall -Wstrict-prototypes -Wno-unused-value
-Wdeclaration-after-statement  -D__XEN_TOOLS__ 
-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-mno-tls-direct-seg-refs -Werror -Wmissing-prototypes
-fno-strict-aliasing  -I. -Wp,-MD,.build.d -m32 -march=i686
-DNDEBUG -std=gnu99 -Wall -Wstrict-prototypes
-Wno-unused-value -Wdeclaration-after-statement 
-D__XEN_TOOLS__  -D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE
-mno-tls-direct-seg-refs -Werror -Wmissing-prototypes
-fno-strict-aliasing  -I. -Wp,-MD,.xc_private.opic.d -fPIC
-c -o xc_private.opic xc_private.c


But I suspect this is because there is:
static __thread xc_error last_error = { XC_ERROR_NONE,
""};
static __thread char errbuf[32];
in xc_private.c 

is there a way to fix/workaroud this ? This is NetBSD
4.0_BETA2

-- 
Manuel Bouyer, LIP6, Universite Paris VI.          
Manuel.Bouyerlip6.fr
     NetBSD: 26 ans d'experience feront toujours la
difference
--

On Wed, Apr 25, 2007 at 07:57:41PM +0200, Manuel Bouyer
wrote:
> But I suspect this is because there is:
> static __thread xc_error last_error = { XC_ERROR_NONE,
""};
> static __thread char errbuf[32];
> in xc_private.c 
> 
> is there a way to fix/workaroud this ? This is NetBSD
4.0_BETA2

You can change it to use
pthread_getspecific/pthread_setspecific, but
that is the only easy way to avoid implementing TLS.

Joerg

On Wed, Apr 25, 2007 at 08:09:35PM +0200, Joerg Sonnenberger
wrote:
> On Wed, Apr 25, 2007 at 07:57:41PM +0200, Manuel Bouyer
wrote:
> > But I suspect this is because there is:
> > static __thread xc_error last_error = {
XC_ERROR_NONE, ""};
> > static __thread char errbuf[32];
> > in xc_private.c 
> > 
> > is there a way to fix/workaroud this ? This is
NetBSD 4.0_BETA2
> 
> You can change it to use
pthread_getspecific/pthread_setspecific, but
> that is the only easy way to avoid implementing TLS.

OK, I think I see how to use it. Does anyone knows the magic
to
call a function at program startup, without calling it from
main() ?

All this is in a library, and I don't want to change each
caller to
do the pthread_key_create() thing ...

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--

On Wed, Apr 25, 2007 at 08:40:47PM +0200, Manuel Bouyer
wrote:
> On Wed, Apr 25, 2007 at 08:09:35PM +0200, Joerg
Sonnenberger wrote:
> > On Wed, Apr 25, 2007 at 07:57:41PM +0200, Manuel
Bouyer wrote:
> > > But I suspect this is because there is:
> > > static __thread xc_error last_error = {
XC_ERROR_NONE, ""};
> > > static __thread char errbuf[32];
> > > in xc_private.c 
> > > 
> > > is there a way to fix/workaroud this ? This
is NetBSD 4.0_BETA2
> > 
> > You can change it to use
pthread_getspecific/pthread_setspecific, but
> > that is the only easy way to avoid implementing
TLS.
> 
> OK, I think I see how to use it. Does anyone knows the
magic to
> call a function at program startup, without calling it
from main() ?
> 
> All this is in a library, and I don't want to change
each caller to
> do the pthread_key_create() thing ...

Well, it's enough to call it at the first call to the
library, if I understood
the man page.

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--

On Apr 25, 2007, at 12:58 PM, Manuel Bouyer wrote:

> Well, it's enough to call it at the first call to the
library, if I  
> understood
> the man page.

..and use pthread_once to make that thread-safe.

>
>
> -- 
> Manuel Bouyer <bouyerantioche.eu.org>
>     NetBSD: 26 ans d'experience feront toujours la
difference
> --

-- thorpej

On Wed, Apr 25, 2007 at 08:40:47PM +0200, Manuel Bouyer
wrote:
> OK, I think I see how to use it. Does anyone knows the
magic to
> call a function at program startup, without calling it
from main() ?

As this is depending on GCC anyway, I bet -- try
__attribute__((__constructor__))

Joerg

On Wed, Apr 25, 2007 at 01:19:29PM -0700, Jason Thorpe
wrote:
> 
> On Apr 25, 2007, at 12:58 PM, Manuel Bouyer wrote:
> 
> >Well, it's enough to call it at the first call to
the library, if I  
> >understood
> >the man page.
> 
> ..and use pthread_once to make that thread-safe.

Good point, I changed my code to use it. Thanks !

-- 
Manuel Bouyer <bouyerantioche.eu.org>
     NetBSD: 26 ans d'experience feront toujours la
difference
--