Remove non-add-on Banner files

  Various subdirectories of glibc include Banner files to put some text
in the output of executing libc.so.6, under "Available extensions".

Some of those subdirectories (e.g. crypt) may originally have been
add-ons (and so optional, so a particular glibc build might or might
not have included them), but except for libidn they aren't now (or if
only included in some builds, in the case of soft-fp, the inclusion
depends on the architecture for which glibc is configured rather than
having any glibc configuration for which it's an optional feature),
and it doesn't seem useful for the libc.so.6 output to call out a few
features like that.

This patch removes the non-add-on Banner files, updating contrib.texi
where they noted contributions not otherwise mentioned there.

Tested for x86_64.

I think it also makes sense to remove the libidn Banner file and the
whole Banner mechanism (there are plenty of configuration choices not
mentioned in the libc.so.6 output, why should this one be special?),
and, independently, to remove the whole add-ons mechanism and just
build libidn via Subdirs.

2017-09-21  Joseph Myers  <joseph@codesourcery.com>

	* crypt/Banner: Remove file.
	* nptl/Banner: Likewise.
	* resolv/Banner: Likewise.
	* soft-fp/Banner: Likewise.
	* nptl/Makefile ($(objpfx)banner.h): Remove rule.
	($(objpfx)version.d): Remove dependency on banner.h.
	($(objpfx)version.os): Likewise.
	* nptl/version.c (banner): Do not include banner.h.
	* manual/contrib.texi: Update entries for Richard Henderson, Jakub
	Jelinek and BIND code.
  

On 09/21/2017 10:56 AM, Joseph Myers wrote:
> Various subdirectories of glibc include Banner files to put some text
> in the output of executing libc.so.6, under "Available extensions".
> 
> Some of those subdirectories (e.g. crypt) may originally have been
> add-ons (and so optional, so a particular glibc build might or might
> not have included them), but except for libidn they aren't now (or if
> only included in some builds, in the case of soft-fp, the inclusion
> depends on the architecture for which glibc is configured rather than
> having any glibc configuration for which it's an optional feature),
> and it doesn't seem useful for the libc.so.6 output to call out a few
> features like that.
> 
> This patch removes the non-add-on Banner files, updating contrib.texi
> where they noted contributions not otherwise mentioned there.
> 
> Tested for x86_64.
> 
> I think it also makes sense to remove the libidn Banner file and the
> whole Banner mechanism (there are plenty of configuration choices not
> mentioned in the libc.so.6 output, why should this one be special?),
> and, independently, to remove the whole add-ons mechanism and just
> build libidn via Subdirs.
> 
> 2017-09-21  Joseph Myers  <joseph@codesourcery.com>
> 
> 	* crypt/Banner: Remove file.
> 	* nptl/Banner: Likewise.
> 	* resolv/Banner: Likewise.
> 	* soft-fp/Banner: Likewise.
> 	* nptl/Makefile ($(objpfx)banner.h): Remove rule.
> 	($(objpfx)version.d): Remove dependency on banner.h.
> 	($(objpfx)version.os): Likewise.
> 	* nptl/version.c (banner): Do not include banner.h.
> 	* manual/contrib.texi: Update entries for Richard Henderson, Jakub
> 	Jelinek and BIND code.
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).
  

On 09/21/2017 10:56 AM, Joseph Myers wrote:
> Various subdirectories of glibc include Banner files to put some text
> in the output of executing libc.so.6, under "Available extensions".
> 
> Some of those subdirectories (e.g. crypt) may originally have been
> add-ons (and so optional, so a particular glibc build might or might
> not have included them), but except for libidn they aren't now (or if
> only included in some builds, in the case of soft-fp, the inclusion
> depends on the architecture for which glibc is configured rather than
> having any glibc configuration for which it's an optional feature),
> and it doesn't seem useful for the libc.so.6 output to call out a few
> features like that.
> 
> This patch removes the non-add-on Banner files, updating contrib.texi
> where they noted contributions not otherwise mentioned there.
> 
> Tested for x86_64.
> 
> I think it also makes sense to remove the libidn Banner file and the
> whole Banner mechanism (there are plenty of configuration choices not
> mentioned in the libc.so.6 output, why should this one be special?),
> and, independently, to remove the whole add-ons mechanism and just
> build libidn via Subdirs.
> 
> 2017-09-21  Joseph Myers  <joseph@codesourcery.com>
> 
> 	* crypt/Banner: Remove file.
> 	* nptl/Banner: Likewise.
> 	* resolv/Banner: Likewise.
> 	* soft-fp/Banner: Likewise.
> 	* nptl/Makefile ($(objpfx)banner.h): Remove rule.
> 	($(objpfx)version.d): Remove dependency on banner.h.
> 	($(objpfx)version.os): Likewise.
> 	* nptl/version.c (banner): Do not include banner.h.
> 	* manual/contrib.texi: Update entries for Richard Henderson, Jakub
> 	Jelinek and BIND code.

Reviewed-by: Carlos O'Donll <carlos@redhat.com>
  

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

On 21 Sep 2017, Carlos O'Donell wrote:

>> 2017-09-21  Joseph Myers  <joseph@codesourcery.com>
>> 
>> 	* crypt/Banner: Remove file.
>> 	* nptl/Banner: Likewise.
>> 	* resolv/Banner: Likewise.
>> 	* soft-fp/Banner: Likewise.
>> 	* nptl/Makefile ($(objpfx)banner.h): Remove rule.
>> 	($(objpfx)version.d): Remove dependency on banner.h.
>> 	($(objpfx)version.os): Likewise.
>> 	* nptl/version.c (banner): Do not include banner.h.
>> 	* manual/contrib.texi: Update entries for Richard Henderson, Jakub
>> 	Jelinek and BIND code.  
>
>Reviewed-by: Carlos O'Donll <carlos@redhat.com>
                          ^
If this is going to be copy-pasted into a commit message, perhaps the
spelling needs fixing (it's different from the sender information in
the email).  ;)
  

On 09/21/2017 03:35 PM, Gabriel F. T. Gomes wrote:
> On 21 Sep 2017, Carlos O'Donell wrote:
> 
>>> 2017-09-21  Joseph Myers  <joseph@codesourcery.com>
>>>
>>> 	* crypt/Banner: Remove file.
>>> 	* nptl/Banner: Likewise.
>>> 	* resolv/Banner: Likewise.
>>> 	* soft-fp/Banner: Likewise.
>>> 	* nptl/Makefile ($(objpfx)banner.h): Remove rule.
>>> 	($(objpfx)version.d): Remove dependency on banner.h.
>>> 	($(objpfx)version.os): Likewise.
>>> 	* nptl/version.c (banner): Do not include banner.h.
>>> 	* manual/contrib.texi: Update entries for Richard Henderson, Jakub
>>> 	Jelinek and BIND code.  
>>
>> Reviewed-by: Carlos O'Donll <carlos@redhat.com>
>                           ^
> If this is going to be copy-pasted into a commit message, perhaps the
> spelling needs fixing (it's different from the sender information in
> the email).  ;)

Typo in my hotkeys. Fixed now :-)

Reviewed-by: Carlos O'Donell <carlos@redhat.com>
  

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,
  

On Wed, 27 Sep 2017, Tulio Magno Quites Machado Filho wrote:

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

It's not clear to me that what I wrote in that paragraph has much 
relevance to the existing standalone libdfp; it was entirely about what 
would be appropriate for a hypothetical integration in glibc, were there 
interest in or consensus for such an integration in the first place.

Declaring using bits/mathcalls.h only makes sense when the functions are 
part of glibc.  (Though it carries implications for projects that do make 
sense for standalone libdfp: where an existing glibc libm function is 
appropriate for DFP types but missing for them in libdfp, as is the case 
for various TS 18661-1 functions in glibc that also exist for DFP in TS 
18661-2, adding the DFP versions to libdfp is appropriate.)

The libm-test machinery is also not particularly designed to be separated 
from the glibc build system; you'd need lots of local changes to use it in 
libdfp (and lots of local changes to make it work with DFP types anyway - 
including an MPFR equivalent for DFP in gen-auto-libm-tests, possibly 
wrapping round GMP and MPFR and using interval arithmetic to get correctly 
rounded DFP results).  Though if you did get it working with libdfp, I 
expect you'd find lots of libdfp bugs that need fixing, e.g. the libdfp 
lgamma / tgamma implementations have issues I fixed in glibc some time 
ago, so making those tests work with libdfp could lead to significant 
improvements in libdfp code quality.
  

Joseph Myers <joseph@codesourcery.com> writes:

> On Wed, 27 Sep 2017, Tulio Magno Quites Machado Filho wrote:
>
>> > 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
>
> It's not clear to me that what I wrote in that paragraph has much 
> relevance to the existing standalone libdfp; it was entirely about what 
> would be appropriate for a hypothetical integration in glibc, were there 
> interest in or consensus for such an integration in the first place.

If we never reach consensus, I'm going to close it.  But I think it's important
to leave traces of this discussion in the libdfp project too.

> Declaring using bits/mathcalls.h only makes sense when the functions are 
> part of glibc.  (Though it carries implications for projects that do make 
> sense for standalone libdfp: where an existing glibc libm function is 
> appropriate for DFP types but missing for them in libdfp, as is the case 
> for various TS 18661-1 functions in glibc that also exist for DFP in TS 
> 18661-2, adding the DFP versions to libdfp is appropriate.)
>
> The libm-test machinery is also not particularly designed to be separated 
> from the glibc build system; you'd need lots of local changes to use it in 
> libdfp (and lots of local changes to make it work with DFP types anyway - 
> including an MPFR equivalent for DFP in gen-auto-libm-tests, possibly 
> wrapping round GMP and MPFR and using interval arithmetic to get correctly 
> rounded DFP results).  Though if you did get it working with libdfp, I 
> expect you'd find lots of libdfp bugs that need fixing, e.g. the libdfp 
> lgamma / tgamma implementations have issues I fixed in glibc some time 
> ago, so making those tests work with libdfp could lead to significant 
> improvements in libdfp code quality.

Ack.