This is the mail archive of the
libc-alpha@sources.redhat.com
mailing list for the glibc project.
Re: Linking TLS in shared libraries
- From: Jakub Jelinek <jakub at redhat dot com>
- To: libc-alpha at sources dot redhat dot com
- Date: Thu, 6 Jan 2005 23:52:31 +0100
- Subject: Re: Linking TLS in shared libraries
- References: <20050106224539.GA27741@nevyn.them.org>
- Reply-to: Jakub Jelinek <jakub at redhat dot com>
On Thu, Jan 06, 2005 at 05:45:39PM -0500, Daniel Jacobowitz wrote:
> I've noticed that all the TLS tests which build a shared library containing
> LD or GD model data aren't (can't be) built with -z defs. This seems
> undesirable... the reason is that GNU ld does not load DT_NEEDED entries
> when linking -shared, for reasons which I don't quite grok. But this is
> what it's done as far back as I checked.
>
> Would it be reasonable to include ld.so in the libc.so linker script? Are
> there any other possible fixes?
Ulrich suggested this week extending ld to handle:
GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a AS_NEEDED ( /lib/ld-linux.so.2 ) )
in the linker script, where the AS_NEEDED would temporarily turn on
as_needed and then restore the previous value of that variable.
I just have not got to implement that yet.
Having ld.so in DT_NEEDED of all programs and all libraries is not
necessary.
Jakub