[LLVMbugs] [Bug 2137] New: link failed glibc-2.7: libc_pic.os: __libc_resp accessed both as normal and thread local symbol

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=2137

           Summary: link failed glibc-2.7: libc_pic.os: __libc_resp accessed
                    both as normal and thread local symbol
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


llvm-gcc4.2 is now able to _compile_ all of glibc (as I stated in a previous
bugreport), however I get a link failure:

make[2]: Leaving directory `/home/edwin/glibc-2.7/build-tree/glibc-2.7/elf'
/home/edwin/llvm/install/bin/llvm-gcc   -shared -static-libgcc -Wl,-O1 
-Wl,-z,defs -Wl,-dynamic-linker=/lib/ld-linux.so.2 
-B/home/edwin/glibc-2.7/build-tree/i386-libc/csu/ 
-Wl,--version-script=/home/edwin/glibc-2.7/build-tree/i386-libc/libc.map
-Wl,-soname=libc.so.6 -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both
-nostdlib -nostartfiles -e __libc_main
-L/home/edwin/glibc-2.7/build-tree/i386-libc
-L/home/edwin/glibc-2.7/build-tree/i386-libc/math
-L/home/edwin/glibc-2.7/build-tree/i386-libc/elf
-L/home/edwin/glibc-2.7/build-tree/i386-libc/dlfcn
-L/home/edwin/glibc-2.7/build-tree/i386-libc/nss
-L/home/edwin/glibc-2.7/build-tree/i386-libc/nis
-L/home/edwin/glibc-2.7/build-tree/i386-libc/rt
-L/home/edwin/glibc-2.7/build-tree/i386-libc/resolv
-L/home/edwin/glibc-2.7/build-tree/i386-libc/crypt
-L/home/edwin/glibc-2.7/build-tree/i386-libc/nptl
-Wl,-rpath-link=/home/edwin/glibc-2.7/build-tree/i386-libc:/home/edwin/glibc-2.7/build-tree/i386-libc/math:/home/edwin/glibc-2.7/build-tree/i386-libc/elf:/home/edwin/glibc-2.7/build-tree/i386-libc/dlfcn:/home/edwin/glibc-2.7/build-tree/i386-libc/nss:/home/edwin/glibc-2.7/build-tree/i386-libc/nis:/home/edwin/glibc-2.7/build-tree/i386-libc/rt:/home/edwin/glibc-2.7/build-tree/i386-libc/resolv:/home/edwin/glibc-2.7/build-tree/i386-libc/crypt:/home/edwin/glibc-2.7/build-tree/i386-libc/nptl
-o /home/edwin/glibc-2.7/build-tree/i386-libc/libc.so -T
/home/edwin/glibc-2.7/build-tree/i386-libc/shlib.lds
/home/edwin/glibc-2.7/build-tree/i386-libc/csu/abi-note.o
/home/edwin/glibc-2.7/build-tree/i386-libc/elf/soinit.os
/home/edwin/glibc-2.7/build-tree/i386-libc/libc_pic.os
/home/edwin/glibc-2.7/build-tree/i386-libc/elf/sofini.os
/home/edwin/glibc-2.7/build-tree/i386-libc/elf/interp.os
/home/edwin/glibc-2.7/build-tree/i386-libc/elf/ld.so -lgcc
/usr/bin/ld: /home/edwin/glibc-2.7/build-tree/i386-libc/libc_pic.os:
`__libc_resp' accessed both as normal and thread local symbol
/home/edwin/glibc-2.7/build-tree/i386-libc/libc_pic.os: could not read symbols:
File format not recognized
collect2: ld returned 1 exit status
make[1]: *** [/home/edwin/glibc-2.7/build-tree/i386-libc/libc.so] Error 1
make[1]: Leaving directory `/home/edwin/glibc-2.7/build-tree/glibc-2.7'
make: *** [all] Error 2


__libc_resp related things I found in the sources:
#define __resp __libc_resp

#if USE__THREAD
#undef __Resp
__thread struct __res_state *__resp = &_res;
extern __thread struct __res_state *__libc_resp
 __attribute__((alias ("__resp"))) attribute_hidden;
#endif

$ readelf -a libc_pic.os|grep resp:
000af232  00189a12 R_386_TLS_GD      00000004   __libc_resp
000afb20  00189a12 R_386_TLS_GD      00000004   __libc_resp
000d8b47  00189a03 R_386_GOT32       00000004   __libc_resp
000d8b5a  00189a03 R_386_GOT32       00000004   __libc_resp
000d8b6f  00189a03 R_386_GOT32       00000004   __libc_resp
000d8b9c  00189a03 R_386_GOT32       00000004   __libc_resp
000d8c03  00189a03 R_386_GOT32       00000004   __libc_resp
000d8c2c  00189a03 R_386_GOT32       00000004   __libc_resp
000d8d73  00189a12 R_386_TLS_GD      00000004   __libc_resp
000da2b5  00189a12 R_386_TLS_GD      00000004   __libc_resp
000da4c5  00189a12 R_386_TLS_GD      00000004   __libc_resp
000da923  00189a12 R_386_TLS_GD      00000004   __libc_resp
000daa1d  00189a12 R_386_TLS_GD      00000004   __libc_resp
000daaf9  00189a12 R_386_TLS_GD      00000004   __libc_resp
000dacb6  00189a12 R_386_TLS_GD      00000004   __libc_resp
000dae5d  00189a12 R_386_TLS_GD      00000004   __libc_resp
000df8fd  00189a12 R_386_TLS_GD      00000004   __libc_resp
000e0b7d  00189a12 R_386_TLS_GD      00000004   __libc_resp
000e134d  00189a12 R_386_TLS_GD      00000004   __libc_resp
000fc38a  00189a12 R_386_TLS_GD      00000004   __libc_resp
000000aa  00189a12 R_386_TLS_GD      00000004   __libc_resp
000000c0  00189a12 R_386_TLS_GD      00000004   __libc_resp
  6298: 00000004     4 TLS     GLOBAL DEFAULT   70 __libc_resp
  7696: 00000004     4 TLS     GLOBAL DEFAULT   70 __resp


I guess that R_386_GOT32 and R_386_TLS_GD conflict, how can I find out _why_
some symbols are R_386_GOT32, and others are R_386_TLS_GD?


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.