This is the mail archive of the
binutils@sourceware.org
mailing list for the binutils project.
Re: Linking problems on CentOS 4.9
- From: Alan Modra <amodra at gmail dot com>
- To: Michael Smith <michael dot smith at puppetlabs dot com>
- Cc: binutils at sourceware dot org
- Date: Thu, 5 Nov 2015 09:20:33 +1030
- Subject: Re: Linking problems on CentOS 4.9
- Authentication-results: sourceware.org; auth=none
- References: <CABy1mMLwQChC4ig_9YaFdr1J-=yGp_d2jg-rh5+M-aJDm3M5sA at mail dot gmail dot com> <87a8qt8xob dot fsf at igel dot home> <CABy1mMKrQsbdJ6OovehPE6-d_i-sZaTHOLJAuOj4qtaj-s=ucA at mail dot gmail dot com>
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