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] |
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.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |