libm error handling

[Joseph S. Myers]

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