Re: Avoid use of libgcc_s and libgcc_eh when building glibc

[Mike Frysinger <vapier at gentoo dot org>]

On Thursday 31 May 2012 06:42:50 Joseph S. Myers wrote:
> On Wed, 30 May 2012, Mike Frysinger wrote:
> > On Monday 28 May 2012 17:43:04 Joseph S. Myers wrote:
> > > ..., so it will work with a minimal libgcc such as GCC can
> > > build with -Dinhibit_libc without needing any libc headers or prebuilt
> > > libc.
> > 
> > this stopped working quite a number of releases ago, and every time
> > patches were posted to gcc to make it work, they were rejected as
> > "install libc headers first".  i'm not sure why we're trying to support
> > a workflow in glibc that gcc isn't going to accept.
> 
> It works for many targets - I routinely build tools for ARM, MIPS, Power,
> x86 like that.

building gcc w/out glibc headers using --without-headers hasn't worked for me 
in quite a long time.  4.6.x was the last one i checked, but haven't bothered 
since as i can now install glibc headers (albeit with a shotgun and a crap ton 
of forced _cv_ vars) first.

i haven't deleted the mechanisms to test a header-less initial gcc build 
though, so i should be able to double check again fairly quickly.

this can also vary drastically based on the target ... IA64 has always needed 
C library headers first, and i'm not sure it's possible to untangle that (due 
to the unwind stuff being so integral to the port).

> The problem is that the existing working process involves configuring and
> building GCC three times and glibc twice: first build a C-only,
> static-only GCC, which can be used to configure glibc to install headers -
> then install a dummy gnu/stubs.h, and crt*.o and a dummy libc.so, by hand
> - then you can build a second C-only GCC with shared libgcc, which can
> build glibc, which then allows a third, full GCC to be built.

the system i've been using works for a variety of glibc/gcc versions:
	- configure + install glibc headers (ignoring the vast sea of errors)
	- configure + build + install C-only static-only gcc
	- configure + build + install full glibc
	- configure + build + install full gcc
for some targets this means the full glibc includes a few symbols from the 
static-only libgcc that a 2nd glibc build wouldn't include (as they'd link 
against libgcc_s), but that seems to be good enough for most people (no one 
has complained yet, and my anal review of exported symbols is the only reason 
i noticed -- runtime has been fine).

> My goal with this patch is to eliminate the following steps: separately
> configuring glibc to install headers; dummy gnu/stubs.c; installing crt*.o
> and dummy libc.so; second GCC with shared libgcc.  There may be further
> changes needed after this patch to get that fully working (to get the
> results of all configure tests the same as if glibc is configured again
> after the final GCC and glibc are built), but by avoiding libgcc_s /
> libgcc_eh dependencies this patch at least gets a substantial part of the
> way there.

if the 1st glibc configure+build+install could be done cleanly and provide 
everything needed so the 1st gcc configure+build+install included a shared 
libgcc, that'd be nice.  it'd make my workflow slightly better, but i'd still 
need 2 gcc runs, so the overall time wouldn't really be affected.

> As Roland noted in
> <http://sourceware.org/ml/libc-alpha/2012-03/msg00960.html>, ideally you
> could configure GCC only *once*.  It may take more work to get there, but
> having a *clean* process (no steps involving installing particular files
> manually) with only two GCC builds and glibc configured only once is still
> a useful improvement on the way there.

i'm not sure we could configure gcc once considering the other targets 
(fortran/etc...) need to do a lot of library checking for available 
functionality.

once we have a complete ABI list of symbols (for the check target), maybe we 
could cheat and generate dummy libraries going backwards from that list :).
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.