[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#478542: marked as done (libc6-dev: tls_get_addr undefined on etch)



Your message dated Sat, 10 May 2008 20:33:04 +0200
with message-id <20080510183304.GA4257@volta.aurel32.net>
and subject line Re: libc6-dev: tls_get_addr undefined on etch
has caused the Debian Bug report #478542,
regarding libc6-dev: tls_get_addr undefined on etch
to be marked as done.

This means that you claim that the problem has been dealt with.
If this is not the case it is now your responsibility to reopen the
Bug report if necessary, and/or fix the problem forthwith.

(NB: If you are a system administrator and have no idea what this
message is talking about, this may indicate a serious mail system
misconfiguration somewhere. Please contact owner@bugs.debian.org
immediately.)


-- 
478542: http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=478542
Debian Bug Tracking System
Contact owner@bugs.debian.org with problems
--- Begin Message ---
Package: libc6-dev
Version: 2.3.6.ds1-13etch5
Severity: normal


I just installed a fresh etch system, and when trying to link my 
application, got an undefined reference error to __tls_get_addr.

The following code / makefile exhibits the problem:

---- test.c ----
static __thread  int foo = 0;

int getfoo()
{
        return foo;
}

---- Makefile ----
all:
        gcc -c -fPIC test.c -o test.o
        gcc -shared -o test.so -Wl,--no-undefined test.o

------------------

If I make the following change to /usr/lib/libc.so, then the app links 
fine:
--- libc.so.orig	2008-04-29 13:20:11.000000000 -0400
+++ libc.so	2008-04-29 13:20:21.000000000 -0400
@@ -2,4 +2,4 @@
    Use the shared library, but some functions are only in
    the static library, so try that secondarily.  */
 OUTPUT_FORMAT(elf64-x86-64)
-GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
+GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( 
/lib/ld-linux-x86-64.so.2 ) )


-- System Information:
Debian Release: 4.0
  APT prefers stable
  APT policy: (500, 'stable')
Architecture: amd64 (x86_64)
Shell:  /bin/sh linked to /bin/bash
Kernel: Linux 2.6.22-2-vserver-amd64
Locale: LANG=en_CA.UTF-8, LC_CTYPE=en_CA.UTF-8 (charmap=UTF-8)

Versions of packages libc6-dev depends on:
ii  libc6                  2.3.6.ds1-13etch5 GNU C Library: Shared libraries
ii  linux-kernel-headers   2.6.18-7          Linux Kernel Headers for developme

Versions of packages libc6-dev recommends:
ii  gcc [c-compiler]              4:4.1.1-15 The GNU C compiler
ii  gcc-4.1 [c-compiler]          4.1.1-21   The GNU C compiler

-- no debconf information



--- End Message ---
--- Begin Message ---
Version: 2.7-1

On Tue, Apr 29, 2008 at 01:27:06PM -0400, Chris AtLee wrote:
> Package: libc6-dev
> Version: 2.3.6.ds1-13etch5
> Severity: normal
> 
> 
> I just installed a fresh etch system, and when trying to link my 
> application, got an undefined reference error to __tls_get_addr.
> 
> The following code / makefile exhibits the problem:
> 
> ---- test.c ----
> static __thread  int foo = 0;
> 
> int getfoo()
> {
>         return foo;
> }
> 
> ---- Makefile ----
> all:
>         gcc -c -fPIC test.c -o test.o
>         gcc -shared -o test.so -Wl,--no-undefined test.o
> 
> ------------------
> 
> If I make the following change to /usr/lib/libc.so, then the app links 
> fine:
> --- libc.so.orig	2008-04-29 13:20:11.000000000 -0400
> +++ libc.so	2008-04-29 13:20:21.000000000 -0400
> @@ -2,4 +2,4 @@
>     Use the shared library, but some functions are only in
>     the static library, so try that secondarily.  */
>  OUTPUT_FORMAT(elf64-x86-64)
> -GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
> +GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a  AS_NEEDED ( 
> /lib/ld-linux-x86-64.so.2 ) )
> 

The problem is not present in version 2.7-1. Marking bug as fixed in
this version in the BTS.

-- 
  .''`.  Aurelien Jarno	            | GPG: 1024D/F1BCDB73
 : :' :  Debian developer           | Electrical Engineer
 `. `'   aurel32@debian.org         | aurelien@aurel32.net
   `-    people.debian.org/~aurel32 | www.aurel32.net


--- End Message ---

Reply to: