state of the install-bootstrap-headers patch

[Helmut Grohne <helmut@subdivi.de>]

Hi,

I'm wondering about the state of a patch that adds a flag
"install-bootstrap-headers" to the Makefile. Let me first try to
summarize the problem, then the solutions taken by various Linux
distributions and then proceed to asking how to move forward.

The <gnu/stubs.h> header defines macros of the form __stubs_$something
for each unimplemented function. It is generated at glibc install time
(not build time) by scanning the generated stubs.  Unfortunately, in a
bootstrap setting we're only installing headers and thus the stubs stuff
goes missing. This tends to result in stubs generation to be broken in
some way or another.

Thus many Linux distributions have come up with quirks to generate a
glibc header installation.

 * Debian/Ubuntu: patch
   https://sources.debian.org/src/glibc/2.27-1/debian/patches/any/local-bootstrap-headers.diff/
 * crosstool-ng: seems to be cargo culting install-bootstrap-headers=yes
   at least, but I couldn't find the actual patch.
 * Fedora/RHEL: workaround
   https://src.fedoraproject.org/rpms/glibc/blob/master/f/STAGE1-glibc-headers#_36
 * Gentoo: workaround
   https://gitweb.gentoo.org/repo/gentoo.git/tree/sys-libs/glibc/glibc-2.27-r1.ebuild#n1271
 * OpenWRT: seems to be cargo culting install-bootstrap-headers=yes at
   least, but I couldn't find the actual patch.
 * Yocto: patch
   http://git.yoctoproject.org/cgit.cgi/poky/plain/meta/recipes-core/glibc/glibc/0018-eglibc-Help-bootstrap-cross-toolchain.patch

The patches are in circulation since around 2007 and were reposted in
2012: https://sourceware.org/ml/libc-alpha/2012-03/msg00237.html The
later discussion wound down figuring whether gcc or glibc should deal
with it and it ended in some dreaming at:
https://sourceware.org/ml/libc-alpha/2012-03/msg00960.html

More than 10 years later, we still deal with this problem (revisited via
<gnu/lib-names.h>) and there still is no upstream solution, because we
cannot agree on what the solution should look like. How can we move this
forward? It causes pain on the distributors. Regardless of what a good
solution would look like, it seems that this solution is practically
being used "everywhere".  At this point I'm under the impression that
refusing the patch causes more harm than good as most users of glibc
have already agreed on how to deal with it.

Please Cc me in replies.

Helmut