Support installing headers for bootstrapping libgcc

[Roland McGrath]

> * Put ldconfig (and sln, if kept at all) in a separate package - 
> maintained by glibc maintainers, released at the same time, but with its 
> own source tree, not part of the libc source tree, and configured and 
> built with an installed compiler and glibc.

I'm not at all comfortable with doing that for something so closely tied
to libc-internal data formats.  Let's see if we can solve the practical
problems without going that route.  We can always reconsider later.

> Splitting out miscellaneous installed executables like that can be seen as 
> part of disentangling and simplifying builds; if something doesn't have a 
> clear need to be built at the same time as libc, building with a complete 
> installed compiler and libc is certainly simpler than building against an 
> uninstalled libc, and if something can be a "normal" application rather 
> than being "special" as part of glibc, I'd rather it was a normal 
> application.

I totally buy this for e.g. zic and memusagestat.  I see the point for
localedef and locale, though that is a harder sell because of the close
integration with a file format not specified anywhere outside of libc.
ldconfig is such a crucial special case that I don't think it makes
nearly as much sense.

> I'll look further into stubbing these things out for ldconfig and sln.

Thanks very much!  I still think we should be going toward dropping sln.
There's just nothing about it that couldn't be adequately handled with a
statically-linked program in some other package like coreutils or
util-linux or whatever.  And, it probably goes without saying, but none
of this seems like a priority for 2.16 (though it may well be simple
enough that there's no special reason to wait if you have the cycles to
spare).


Thanks,
Roland