This is the mail archive of the
libc-alpha@sourceware.org
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.4.64.1205282140020.2726@digraph.polyomino.org.uk><20120529235232.E0F742C0B8@topped-with-meat.com><Pine.LNX.4.64.1205301052380.25659@digraph.polyomino.org.uk><877gvt8hi0.fsf@schwinge.name><87txyoksdr.fsf@schwinge.name><20120606221104.AEA162C096@topped-with-meat.com><Pine.LNX.4.64.1206081142100.3499@digraph.polyomino.org.uk>
> 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
> driver.
Hmm. It looks like that could be defeated by something like
CPPFLAGS=-DENABLE_SHARED_LIBGCC.
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.
Thanks,
Roland