[RFC] preliminary patch to move decimal float runtime to new libs

[Joseph S. Myers]

On Tue, 19 Aug 2008, H.J. Lu wrote:

> I guess it depends on which shared library the runtime DFP will be in.
> If DFP becomes the part of C/C++ standard and the DFP run-time support
> goes into libc.so, we will need libgcc_dfp.so for every application. I
> don't know if it is a good idea. I think we should first figure where the
> final runtime DFP wil be before we make a new DFP shared library.

Becoming part of the standard (which in any case doesn't appear to be 
happening for C1x) does not mean going in libc.so; it might mean the 
add-on is integrated into the standard glibc distribution, but still 
builds a separate shared library, just like libm is separate although it 
defines functions that are part of the standard, and just like various 
parts of POSIX have their own libraries such as libpthread and librt.

Much the same applies to other TRs, draft TRs, etc., that might or might 
not get integrated and define library facilities:

TR 18037 (embedded C - fixed point etc.; I don't know of an implementation 
of the library facilities for GNU)

TR 19769 (extra character datatypes - this *is* expected to go into C1x, 
but it only has four functions and there probably isn't much point in a 
separate shared library for them; I don't know of an implementation of the 
library facilities for GNU)

DTR 24731-1 (MS bounds-checking functions - rejected for glibc as long as 
they aren't in the standard; I don't know of an implementation for GNU)

DTR 24731-2 (POSIX/GNU dynamic allocation functions - mostly already in 
glibc, but not some of the wide character variants)

DTR 24732 (DFP - which we're discussing now)

DIS 24747 (special mathematical functions; I don't know of an 
implementation for GNU)

-- 
Joseph S. Myers
joseph@codesourcery.com