This is the mail archive of the 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: Avoid use of libgcc_s and libgcc_eh when building glibc

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.

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

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

As Roland noted in 
<>, 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've tested this patch for x86_64 and also done a test build for ARM.
> > To go in it will certainly need more architecture testing (libc
> > architectures and IA64)
> IA64 is the most pita Linux target i've found to create a cross-compiler.  in 

The testing I want is simply of a build where a prebuilt IA64 glibc 
already exists.  That is, to make sure the patch (possibly with

gnulib-arch = $(libgcc_eh)
static-gnulib-arch = -lgcc_eh $(libunwind)

in an IA64 sysdeps makefile) doesn't make things any worse, even if it 
doesn't actually make bootstrap easier for IA64 either.

Joseph S. Myers

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