Re: Support installing headers for bootstrapping libgcc

[Roland McGrath <roland at hack dot frob dot com>]

> So how should these static linking issues be addressed?  By arranging for 
> the versions of the functions that use dlopen to be used in sln and 
> ldconfig?  By arranging for dummy versions that just abort to be used in 
> those programs?  By having appropriate makefile variables and targets to 
> build and install glibc without these programs and then later build and 
> install these programs after libgcc_eh has been built and installed?

I don't like the last option.  IMHO it should be a last resort only if the
issues are intractable.  It leaves us with the build-and-build-it-again
bootstrap sequence that we are trying to eliminate.

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?

That leaves only ldconfig, which is statically-linked for a much more
defensible reason.  (It really does need to be run on a live system
that's in the middle of having its shared libraries installed.)

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.


Thanks,
Roland