Re: [patches] libdfp

[Mark Mitchell <mark@xxxxxxxxxxxxxxxx>]

Joseph S. Myers wrote:

> I'm not clear on what ratification has to do with existing as standalone 
> or not standalone.  In any case, the ISO catalogue shows that TR 
> 24732:2009 was published 2009-01-05 and is available for 112 Swiss francs.

I'm not even clear on how ISO status of any kind is particularly
relevant.  Part of EGLIBC's purpose is to accommodate non-standard (and,
in particular, architecture-specific) enhancements.  (Of course, option
groups can be used to configure such things and they can be off by
default.)  In the original discussions of EGLIBC, things like
Freescale's SPE math functions and special printf format specifiers for
architecture-specific types were discussed.  The C library isn't pure of
purpose; it's full of goop accumulated over the years from C language
implementations, UNIX-like system implementations, and so forth.

Even the question of whether or not to put new APIs in a different .so
is not obvious; if most applications will want the new APIs, then they
probably should not be in a separate .so, as that will increase overhead
rather than reduce it.

In this case, it seems like we all think the technically best answer is
to make DFP an add-on, in the traditional GLIBC sense of the word.  But,
apparently, Ryan thinks that's not going to be successful, for
non-technical reasons.

Ryan, how about checking it in as a proper add-on, and then having an
alternate build system (also potentially checked in) that could be used
to build it stand-alone?  People can always checkout the add-on
subdirectory from SVN without the rest of the tree.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@xxxxxxxxxxxxxxxx
(650) 331-3385 x713