Re: Support installing headers for bootstrapping libgcc

["Joseph S. Myers" <joseph at codesourcery dot com>]

On Fri, 11 May 2012, Roland McGrath wrote:

> I think we can just get rid of sln entirely at this point.  We really
> don't expect anybody to be able to run 'make install' directly on a
> live system and not ruin all sorts of things that might be needed
> somewhere in the process.  So why should ln be different?

If you no longer support "make install" into the root of a live system, 
then that opens another option I didn't mention:

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

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.

But while memusagestat has a very strong case for splitting out like that 
(it depends on various non-glibc libraries such as GD, so can't possibly 
be built at the same time as glibc in a bootstrap, and doesn't really 
depend on glibc internals as far as I know), and various other installed 
pieces may similarly not be closely tied into glibc internals, I presumed 
we should still keep "make install" on a live system working (even though 
the norm is certainly to install with install_root set and have package 
managers deal with the issues involved in replacing the system's active 
libc), and so ldconfig should stay as part of the main build.

> Let's look a little deeper into what the particular references in
> linking ldconfig are and where they come from.  It seems likely that
> we can stub things out pretty simply so that we don't lose anything
> that matters.  I tried adding:
> 
> /* Include our own copy of __libc_fatal that doesn't call backtrace
>    (as linux/libc_fatal.c does) and bring in all those dependencies.  */
> #include <sysdeps/posix/libc_fatal.c>
> 
> at the end of ldconfig.c and after this the only things look to be
> stuff from libio that is for cancellation support, which ldconfig
> really does not need.  I haven't looked into how to stub those out,
> which might well depend on machine/compiler version.  But I think it's
> worth (someone) investigating how hairy it really is.

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

-- 
Joseph S. Myers
joseph@codesourcery.com