This is the mail archive of the
mailing list for the glibc project.
Re: Avoid use of libgcc_s and libgcc_eh when building glibc
- From: Roland McGrath <roland at hack dot frob dot com>
- To: "Joseph S. Myers" <joseph at codesourcery dot com>
- Cc: Thomas Schwinge <thomas at codesourcery dot com>, libc-alpha at sourceware dot org
- Date: Tue, 12 Jun 2012 10:27:03 -0700 (PDT)
- Subject: Re: Avoid use of libgcc_s and libgcc_eh when building glibc
- References: <Pine.LNX.firstname.lastname@example.org><20120529235232.E0F742C0B8@topped-with-meat.com><Pine.LNX.email@example.com><firstname.lastname@example.org><email@example.com><20120606221104.AEA162C096@topped-with-meat.com><Pine.LNX.firstname.lastname@example.org>
> On Wed, 6 Jun 2012, Roland McGrath wrote:
> > > I can now do: binutils, GCC "configure --disable-shared --disable-threads
> > > --without-headers --with-newlib" [...] complete GCC, [...]
> > Do any of those configure options affect gcc proper, or only the target
> > libraries? That is, is the "complete GCC" step rebuilding the compiler in
> > a way that matters, or just completing the build of the target libraries?
> At least --disable-shared does affect the specs built in to the GCC
Hmm. It looks like that could be defeated by something like
But I think all those --disable-*/-with* options are really just intended
to affect libgcc, right? So I wonder if there might not be a better
procedure in which one builds gcc proper with the normal/final set of
configuration options and only specially configures a libgcc build to be
used for the libc build.
No doubt some hacking of the gcc top-level makefile stuff would make that
easier. Perhaps there is some sensible way to teach it about a new target
build variant (i.e. as if it were a different multilib alternative) that
builds just libgcc and uses extra configure options for that build.