public inbox for libc-alpha@sourceware.org
 help / color / mirror / Atom feed
From: Carlos O'Donell <carlos@redhat.com>
To: Florian Weimer <fweimer@redhat.com>,
	Joseph Myers <joseph@codesourcery.com>
Cc: GNU C Library <libc-alpha@sourceware.org>
Subject: Re: Symbol versioning for secondary libraries is not effective
Date: Mon, 29 Jan 2018 23:58:00 -0000	[thread overview]
Message-ID: <e0036a78-2327-78d3-50de-beda982706f9@redhat.com> (raw)
In-Reply-To: <26f4b544-d00e-adef-a31a-3b34eeae96ee@redhat.com>

On 01/29/2018 12:58 AM, Florian Weimer wrote:
> On 01/26/2018 01:46 PM, Joseph Myers wrote:
>> On Fri, 26 Jan 2018, Florian Weimer wrote:
>>
>>> in mind for future changes.  It is also a mild argument in favor of moving
>>> symbols into libc.so.6, I think.
>>
>> Suppose you make the libc.so linker script reference some or all of the
>> other libraries inside AS_NEEDED.  Do that result in them being
>> automatically linked into shared libraries that use symbols from them, or
>> does it only work for executables?
> 
> This will not work for libpthread because some libraries really prefer to link against the libc.so.6 definitions, at least for the time being, where the libc and libpthread implementations offer different trade-offs.
> 
> For libm and libld, this approach appears to work.  The AS_NEEDED directive is even overriden by an explicit -lm or -ldl on the command, which is good.  It looks like this is something to consider for the next release.
> 
>> Referencing libraries inside AS_NEEDED is arguably friendlier to users
>> anyway - e.g. those not familiar with Unix conventions may not expect to
>> need to use -lm.
> 
> Yes, a missing -lm seems to be a common obstacle.

I think an AS_NEEDED for -lm and -ldl would be a step in the right direction.

The only complaint might be that the accidental use of such a symbol will pull
in the new library instead of generating an error, but it's hard to argue this
case. You can always later remove the reference and recompile the program.

-- 
Cheers,
Carlos.

      reply	other threads:[~2018-01-29 21:06 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-26 10:41 Florian Weimer
2018-01-26 13:55 ` Joseph Myers
2018-01-29 14:00   ` Florian Weimer
2018-01-29 23:58     ` Carlos O'Donell [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=e0036a78-2327-78d3-50de-beda982706f9@redhat.com \
    --to=carlos@redhat.com \
    --cc=fweimer@redhat.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-alpha@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).