This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Remove non-add-on Banner files


Joseph Myers <joseph@codesourcery.com> writes:

> On Thu, 21 Sep 2017, Carlos O'Donell wrote:
>
>> This looks good to me. We have less use of add-ons lately, but *before*
>> we remove add-ons I'd like to talk again about bringing libdfp into
>> glibc as a fully supported add-on (even if not via add-ons the mechanism).
>
> I don't see libdfp as being of any relevance to the possible removal of 
> the add-ons mechanism.  It used to be a glibc add-on, but that was 
> replaced by a standalone build system many years ago.  We have various 
> optional libraries in glibc such as libnsl and libmvec, controlled by 
> ordinary --enable options.
>
> Any libdfp integration in glibc would I expect also look very different, 
> as regards build system and general integration, from either the present 
> build system or the old add-on version.  For example, functions would be 
> declared directly in the relevant headers under appropriate __GLIBC_USE 
> conditionals (in bits/mathcalls.h in many cases - most functions should be 
> present for both binary and decimal types).  Tests would use the libm-test 
> / auto-libm-test machinery, adapted as necessary to support DFP; the vast 
> bulk of test inputs to most functions should be applicable to both binary 
> and decimal floating point.  (The actual function implementations would I 
> expect not need changing much for glibc.)

I created an issue in the libdfp project [1] to track these changes.

[1] https://github.com/libdfp/libdfp/issues/63

Thanks,

-- 
Tulio Magno


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]