I have an esoteric problem that I'm a little stuck on, and would
appreciate any advice on debugging further.
I'm trying to build a C++ project using GCC 4.8.2 and ld 2.2.5 on
CentOS 4.9 (which comes with glibc 2.3.4). When I try to build a
simple C++ program:
> #include <string>
> #include <cstdio>
> #include <cstdlib>
> extern char **environ;
> int main(int argc, char** argv)
> {
> setenv("A", "", 1);
> unsetenv("A");
> std::string s ("A");
> setenv("A", "", 1);
> printf("%x (should be a valid pointer)\n", *environ);
> return 0;
> }
using '-static-libgcc -static-stdlibc++', I get an error
>
> /opt/pl-build-tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../x86_64-unknown-linux-gnu/bin/ld: /opt/pl-build-tools/lib/gcc/x86_64-unknown-linux-gnu/4.8.2/../../../../lib64/libstdc++.a(eh_globals.o): undefined reference to symbol '__tls_get_addr@@GLIBC_2.3'
> /lib64/ld-linux-x86-64.so.2: error adding symbols: DSO missing from command line
> collect2: error: ld returned 1 exit status
That happens despite __tls_get_addr being defined in
/lib64/ld-linux-x86-64.so.2, and the link command including
'-dynamic-linker /lib64/ld-linux-x86-64.so.2'. Some suggestions I've
found are to include ld-linux as part of the compile, which causes the
program to successfully link but then corrupt 'environ' when run.
I can get a working executable by dynamically linking libstdc++ (which
is likely the route I'll have to take) but I'm confused why this is a
problem. Also using the system binutils for ld (version 2.15.92.0.2)
seems to work, but causes problems linking more complicated C++11
code.
