Undefined reference to symbol '___tls_get_addr@@GLIBC_2.3' '

Linux specific questions.
Post Reply
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Undefined reference to symbol '___tls_get_addr@@GLIBC_2.3' '

Post by counting_pine »

Does anyone get an error with this code?

Code: Select all

type t
	declare constructor( )
	as integer ptr p = new integer
end type

constructor t( )
end constructor

'' ld: /usr/lib/gcc/i686-linux-gnu/4.7/libsupc++.a(eh_globals.o): undefined reference to symbol '___tls_get_addr@@GLIBC_2.3'
'' ld: note: '___tls_get_addr@@GLIBC_2.3' is defined in DSO /lib/i386-linux-gnu/ld-linux.so.2 so try adding it to the linker command line
'' /lib/i386-linux-gnu/ld-linux.so.2: could not read symbols: Invalid operation
I'm using a Git build of fbc on Ubuntu 12.10. But I've tried a Ubuntu 12.04 system that works, so I'm wondering whether Ubuntu or I have broken something. If it's my fault, I have no idea how to fix it..
TJF
Posts: 3809
Joined: Dec 06, 2009 22:27
Location: N47°, E15°
Contact:

Re: Undefined reference to symbol '___tls_get_addr@@GLIBC_2.

Post by TJF »

A 32 / 64 bit issue? (I'm just guessing.)
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Undefined reference to symbol '___tls_get_addr@@GLIBC_2.

Post by counting_pine »

I (definitely) should also have mentioned: both installs are 32-bit.

The mentions of both i386 and i686 is perhaps a clue to the problem. Though I really don't know. For the most part, Ubuntu is just a well-organised black box to me.
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Undefined reference to symbol '___tls_get_addr@@GLIBC_2.

Post by dkl »

Apparently it is gcc's libsupc++.a that needs this symbol, I think FB code only uses libsupc++ for NEW/DELETE.

I suspect it's another piece of the multiarch puzzle. fbc uses -dynamic-linker /lib/ld-linux.so.2 when linking, maybe we'd need to use /lib/i386-linux-gnu/ld-linux.so.2 here as suggested by that ld message?

It is weird though, I thought there were symlinks in place to prevent having to adjust paths like this... does Ubuntu i386 not have /lib/ld-linux.so.2 anymore, or is it really different from /lib/i386-linux-gnu/ld-linux.so.2? (could try comparing nm output, the list of symbols)

Another thing to try would be to compile a similar C/C++ program with gcc/g++ and see what ld options it will use, for comparison, then possibly adjust fbc to do the same if possible.

By the way, in the Debian/Ubuntu world they use i386 for all 32bit x86, often the system compiler is really something different though, for example I see i686 on recent Ubuntus and remember i486 toolchains from others.
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Undefined reference to symbol '___tls_get_addr@@GLIBC_2.

Post by marcov »

And when statically linking that C++ program also check what libs are really linked.

While I never have looked into it in recent times, I can vaguely remember something about libc.a only containing the core libc code, and not the other libs that are combined to glibc.so (like iconv). It could be that TLS stuff is some other .a.

Another possibility is that libraries are not implicitely linked when not dynamic linking. (think libpthreads and libgcc here)
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Undefined reference to symbol '___tls_get_addr@@GLIBC_2.

Post by dkl »

I installed a Ubuntu 12.10 VM and I can reproduce this linking error easily with FB 0.23 and 0.24, using just this:

Code: Select all

dim p as integer ptr = new integer
But I can compile to .o and use g++ to link just fine:
$ FreeBASIC-0.24.0-linux/bin/fbc 1.bas -c -m 1
$ g++ 1.o -o 1 -LFreeBASIC-0.24.0-linux/lib/freebasic -lfb -lncurses -pthread
So it definitely is the difference in ld command line...
marcov
Posts: 3455
Joined: Jun 16, 2005 9:45
Location: Netherlands
Contact:

Re: Undefined reference to symbol '___tls_get_addr@@GLIBC_2.

Post by marcov »

I compiled a mininal C program with -static and use strace to obtain the linker cmdline

strace -s 131072 -f -v gcc -static test.c &>syscall.log

In the output I search for "/bin/ld" to see where the linker was called (2nd or 3rd occurance), and got the linker commandline

(this was all on one line, I splitted it for easier explanation

[pid 29148] execve("/usr/bin/ld", ["/usr/bin/ld", "--build-id", "--no-add-needed", "-m", "elf_i386", "--hash-style=gnu", "-static", "/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crt1.o", "/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crti.o", "/usr/lib/gcc/i686-redhat-linux/4.5.1/crtbeginT.o", "-L/usr/lib/gcc/i686-redhat-linux/4.5.1", "-L/usr/lib/gcc/i686-redhat-linux/4.5.1/../../..", "/tmp/cctW5cUY.o", "--start-group", "-lgcc", "-lgcc_eh", "-lc", "--end-group", "/usr/lib/gcc/i686-redhat-linux/4.5.1/crtend.o", "/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crtn.o"],

which is the main linker commandline. Note the libgcc_eh. the rest (after the closing ] ) is the environment, and can be useful for LD_FLAGS, C_FLAGS etc:

["HOSTNAME=atlas.localdomain", "SELINUX_ROLE_REQUESTED=", "TERM=xterm", "SHELL=/bin/bash", "HISTSIZE=1000", "SELINUX_USE_CURRENT_RANGE=", "QTDIR=/usr/lib/qt-3.3", "OLDPWD=/usr/lib/gcc/i686-

(clipped to keep post size down)

I looked at libgcc_eh with NM, and it seems to contain a bunch of tls symbols, prefixed with __emu.

My guess would be that these are symbols that are different when linked to cpp vs plain C.

But that turned out wrong. I compiled exactly the same program with g++ (after installing static libs), and the commandline is pretty much the same.

[pid 29333] execve("/usr/bin/ld", ["/usr/bin/ld", "--build-id", "--no-add-needed", "-m", "elf_i386", "--hash-style=gnu", "-static", "/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crt1.o", "/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crti.o", "/usr/lib/gcc/i686-redhat-linux/4.5.1/crtbeginT.o", "-L/usr/lib/gcc/i686-redhat-linux/4.5.1", "-L/usr/lib/gcc/i686-redhat-linux/4.5.1/../../..", "/tmp/ccB9MVoT.o", "-lstdc++", "-lm", "--start-group", "-lgcc", "-lgcc_eh", "-lc", "--end-group", "/usr/lib/ gcc/i686-redhat-linux/4.5.1/crtend.o", "/usr/lib/gcc/i686-redhat-linux/4.5.1/../../../crtn.o"],

["HOSTNAME=atlas.localdomain", "SELINUX_ROLE_REQUESTED=", "TERM=xterm", "SHELL=/bin/bash", "HISTSIZE=1000"

(clipped again.

I hoped I gave a quick idea how to tackle such problems. Not the most elegant way probably, but easy to remember (I only do this every so and so many years)
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Re: Undefined reference to symbol '___tls_get_addr@@GLIBC_2.

Post by counting_pine »

dkl wrote:I installed a Ubuntu 12.10 VM and I can reproduce this linking error easily with FB 0.23 and 0.24, using just this:

Code: Select all

dim p as integer ptr = new integer
Heh. I whittled my code down from a unit test, guess I didn't do enough whittling..
If FB is unable to use New/Delete on the latest version of a popular OS, that's pretty serious, right?

Can g++ be persuaded to reveal its ld command line more simply? (I find the contents of the last post a little overwhelming..)
dkl
Site Admin
Posts: 3235
Joined: Jul 28, 2005 14:45
Location: Germany

Re: Undefined reference to symbol '___tls_get_addr@@GLIBC_2.

Post by dkl »

I agree it's important to solve this. gcc/g++ support the -v (verbose) option which will show the linking command line, much like fbc. It can also help to look at the ld map files (fbc -map map.txt and g++ -Wl,-Map,map.txt).

Maybe it's just a problem of -l option order (that happens even when using ld's -( -) group options if libs have duplicate symbols)
-l fb -l gcc -l pthread -l c -l m -l dl -l ncurses -l supc++ -l gcc_eh
If I change the order of -l options the error goes away (this order is derived from gcc):
FreeBASIC-0.24.0-linux/bin/fbc FreeBASIC-0.24.0-linux/lib/freebasic/fbrt0.o 1.bas -nodeflibs -l fb -l ncurses -l tinfo -l m -l supc++ -l pthread -l gcc -l gcc_eh -l c
It seems like the problem only shows up if -lsupc++/-lstdc++ appear behind -lc, fixing this solves the problem. Another thing that seemed to work was to link against libstdc++ like g++, instead of just the libsupc++ part of it. I think the only reason fbc does that was to prevent having to distribute the huge libstdc++ binary, but since our FB-Linux release don't include prebuilt gcc libs anymore nowadays this is not an issue anymore.
TuxForAll
Posts: 37
Joined: Jun 24, 2007 13:18

Re: Undefined reference to symbol '___tls_get_addr@@GLIBC_2.

Post by TuxForAll »

Hello,

the same on Fedora 18 32bit

tuxforall
Post Reply