public inbox for libc-ports@sourceware.org
 help / color / mirror / Atom feed
From: Roland McGrath <roland@hack.frob.com>
To: Richard Henderson <rth@twiddle.net>
Cc: libc-ports@sourceware.org,    joseph@codesourcery.com
Subject: Re: [RFC] BZ 15666: alpha: Add __sqrt*_finite definitions
Date: Mon, 24 Jun 2013 21:57:00 -0000	[thread overview]
Message-ID: <20130624215704.546782C09B@topped-with-meat.com> (raw)
In-Reply-To: Richard Henderson's message of  Monday, 24 June 2013 10:07:07 -0700 <1372093627-26874-1-git-send-email-rth@twiddle.net>

> This doesn't quite work.  The __sqrtl_finite version gets emitted to
> the wrong version.  I had thought that adding symbols to the Versions
> file at a later version would override earlier symbols in the more
> generic Versions file, but it appears that isn't so?

Nope.  Our machinery just pastes them together, so libm.map lists
both.  The linker chooses the earliest one.

> Must I solve this with an explicit versioned_symbol macro, or is there
> a better way?

Without touching non-alpha files, you must.  

Without affecting any other configuration, you could add something
like '%ifdef __alpha__' to math/Versions (but you'd be shot).

Without touching infrastructure, you could move __sqrtl_finite out of
the shared math/Versions and put it into machine-specific
sysdeps/.../Versions files so that it appears only once in libm.map
and always in the right set for each machine.  But that is a bit of a
nightmare of duplication and a recipe for maintenance hell if we try
to make everybody do everything this way from the start (at least as
everything else stands today).

Finally, we could rethink our whole infrastructure for producing the
version maps and rejigger things to make these cases easier to handle.
Thoughtful suggestions welcome.  This is probably what we should be
doing, but obviously not this week.


Thanks,
Roland

  parent reply	other threads:[~2013-06-24 21:57 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-06-24 17:07 Richard Henderson
2013-06-24 20:24 ` Joseph S. Myers
2013-06-24 21:57 ` Roland McGrath [this message]
2013-06-25  0:10   ` Richard Henderson
2013-06-25  2:01 ` Richard Henderson
2013-06-25 13:35   ` Joseph S. Myers

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=20130624215704.546782C09B@topped-with-meat.com \
    --to=roland@hack.frob.com \
    --cc=joseph@codesourcery.com \
    --cc=libc-ports@sourceware.org \
    --cc=rth@twiddle.net \
    /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).