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


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.)

libdfp is not a very active project (no commits in the past year, though 
some recent issue tracker activity), so I don't really see the work 
required for a clean glibc integration happening any time soon (and there 
would also be the question of whether it's sufficiently specialized that 
it makes more sense for it to remain a separate project).

(Even with it as a separate project I'd admit the possibility of glibc 
changes intended to work with it.  For example, making glibc headers 
include libdfp-provided headers under appropriate __GLIBC_USE 
conditionals.  For example, if any configurations of libdfp use a software 
TLS DFP rounding mode, putting that rounding mode in libc so that 
fegetenv, fesetenv, feupdateenv, fegetmode, fesetmode can save and restore 
it as they should.)

-- 
Joseph S. Myers
joseph@codesourcery.com


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