Linking problems on CentOS 4.9

[Alan Modra]

On Wed, Nov 04, 2015 at 10:43:02AM -0800, Michael Smith wrote:
> My expectation from compiling with the system ld, and on every other
> system I've built on (a large number), is that is sufficient for
> resolving __tls_get_addr at runtime. With successful builds I see a
> dependency setup against /lib64/ld-linux-x86-64.so.2 without having to
> specify it explicitly.

Andreas is correct.  Normally, TLS sequences are optimised by the
linker when linking an executable, so there won't be any references
to __tls_get_addr left to cause undefined symbol errors.  However, if
you are linking statically and the link optimisation fails or is
disabled by a linker option, then the static libc needs to provide
__tls_get_addr.  If you are not linking statically, then glibc's
libc.so is a linker script that arranges to include libc.so.6,
libc_nonshared.a, and on x86_64, ld-linux-x86-64.so.2.

> On Wed, Nov 4, 2015 at 9:46 AM, Andreas Schwab <schwab@linux-m68k.org> wrote:
> > Michael Smith <michael.smith@puppetlabs.com> writes:
> >
> >> 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'.
> >
> > -dynamic-linker only sets the interpreter section, it does not add
> > anything to the list of linked objects.

-- 
Alan Modra
Australia Development Lab, IBM