This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Support installing headers for bootstrapping libgcc


> I don't think libgcc is the right place for that sort of detail about what 
> headers are needed internally by other headers but not installed by glibc; 

And I don't think glibc is the right place for much of any detail about
what building gcc requires.

A simple ideal would be that you can just build the compiler proper (no
nontrivial target libraries) and then use that to build glibc.  We're
not quite there, and perhaps there are good reasons for that.  But I
really think we need a fresh consideration from the ground up of what
all the tangled dependencies are and, more importantly, which are truly
required.

1. Why do we need libgcc at all just to build glibc?

   By this I mean literally to build it, i.e. not to run anything, tests
   or anything else.  (Take as given that anything like rpcgen was or
   localedef is, i.e. where we run just-built programs as part of the
   build, would be avoided somehow as we've discussed separately.)

   I guess some bits of libgcc might be required to link the DSOs
   themselves, depending on the machine.  Can we cite what those are?

   I think only the traditional libgcc fodder should really be in that
   category (e.g. __muldi3).  Nothing for EH should really be required,
   since we use libgcc_s.so only at runtime via dlopen.

   What else is there?

2. Why do we need anything from glibc just to build libgcc?

   The traditional libgcc bits are pure CPU-using code.
   No system headers should be required to build that stuff.
   If they are, it just seems like laziness in the organization
   of the libgcc code.  Is there something I'm overlooking?

   What else is there?  Maybe libgcc sometimes wants to call abort, or
   some syscall for cache-flushing or the like.  Does it really need
   headers for that?  These things have well-established signatures,
   so it can just use its own declarations.

   The libgcc_s.so EH stuff needs to call dl_iteratephdr.  OK, that
   reasonably requires a header.  But, as mentioned above, we don't
   really need to build libgcc_s.so before we build libc, do we?

   What else is there?

I've made it sound simple and of course I know it's actually harder than
that.  But I'm pretty confident that it really doesn't need to be nearly
as hard as we've made it.  I'm not convinced there truly need to be any
circular dependencies at all.  So let's step back and figure out how it
really ought to be and can be.

Ideally the bootstrap procedure would be:

	1. Build binutils.  
	   This thankfully already has no target dependencies.
	   Kudos binutils.
	2. Build the compiler itself.
	   Today this is influenced by some things like configure checks
	   that change how the compiler behaves based on analysis of
	   libc's features.  But it doesn't really have to be that way.
	   We can find better ways to make those configuration
	   decisions.  
	3. Use that compiler to build the "basic" libgcc.
	   By that I mean what libgcc originally was long ago: just the
	   things that the compiler generates calls to for basic
	   operations like arithmetic and so forth.  In the ideal, this
	   would have zero requirements of target anything (like headers),
	   just the compiler, the assembler, and ar.
	4. Use that compiler and libgcc to build glibc.
	5. Build the higher-level target libraries that come with gcc.
	   This includes libgcc_s.so as well as libstdc++ et al.

Let's figure out how close we can get to this ideal and what needs to
change to get us there.


Thanks,
Roland


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]