This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: libm error handling
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Rich Felker <dalias at aerifal dot cx>
- Cc: <libc-alpha at sourceware dot org>
- Date: Tue, 30 Apr 2013 19:18:20 +0000
- Subject: Re: libm error handling
- References: <Pine dot LNX dot 4 dot 64 dot 1304301628510 dot 21969 at digraph dot polyomino dot org dot uk> <20130430181544 dot GG20323 at brightrain dot aerifal dot cx>
On Tue, 30 Apr 2013, Rich Felker wrote:
> I'm glad to see an effort to clean up this historical mess.
>
> On Tue, Apr 30, 2013 at 04:30:43PM +0000, Joseph S. Myers wrote:
> > As far as I can tell, POSIX only reserves the identifier signgam
> > with external linkage when math.h is included with _XOPEN_SOURCE
> > defined appropriately to enable XSI extensions, not otherwise (there
> > is a long list of symbols with external linkage that are always
> > reserved, and it does not include signgam). So I think the
> > following should work for a fix: the lgamma symbol versions
> > presently in use are made into compat symbol versions, for existing
> > binaries where lgamma is expected to set signgam (except for
> > _ISOC_). The new version of the lgamma symbol does not set signgam,
> > while a separate __lgamma_xsi function is defined that does set
> > signgam, and is used when math.h is included with appropriate
> > feature test macros defined.
>
> This should not be necessary. signgam should simply be a weak alias
> for __signgam or similar, and lgamma should only write to __signgam.
> However, some serious black magic may be needed with symbol versioning
> to keep old binaries happy...
That would certainly be simpler if it works. The issue with existing
binaries is that they might either use the signgam from the shared libm,
or define their own to which references from libm would then have
referred, and in either case such binaries should continue to work, even
if we say that newly linked binaries expecting to use signgam must not
define their own copy. If a binary defines its own, references to
__signgam within libm aren't going to refer to the binary's copy of
signgam - unless the reference within libm is to the symbol called
signgam, I don't think the binary's copy will override it.
Maybe you need symbol versioning to separate the old version of lgamma
that writes to signgam for old binaries, and the new one that writes to
__signgam for new binaries.
--
Joseph S. Myers
joseph@codesourcery.com