Linking problems on CentOS 4.9

[Michael Smith <michael dot smith at puppetlabs dot com>]

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.25 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.

I've also run into this problem with my own static libraries that use
threads (haven't completely isolated the test case) when linking them
into a binary. If I compile the object files directly to a shared library, I
don't run into a problem.