This is the mail archive of the
mailing list for the GCC project.
Re: RFC: Always build libgcc_eh.a
- From: Richard Henderson <rth at redhat dot com>
- To: gcc-patches at gcc dot gnu dot org
- Date: Fri, 11 Feb 2005 13:46:41 -0800
- Subject: Re: RFC: Always build libgcc_eh.a
- References: <20050211203524.GA7617@nevyn.them.org>
On Fri, Feb 11, 2005 at 03:35:24PM -0500, Daniel Jacobowitz wrote:
> I'm not 100% sure this patch is a good idea, but it would be convenient for
> me. All comments appreciated.
> The problem I'm trying to solve is an inconsistency between two i386-linux
> toolchains; one configured with --enable-shared and one configured with
> --disable-shared. In the --enable-shared configuration we have:
> libgcc.a - Support routines, not including EH
> libgcc_eh.a - EH support routines
> libgcc_s.so - Support routines, including EH
> In the --disable-shared configuration we have:
> libgcc.a - That's all you get, folks - all routines
> When building glibc, there are a couple of places where it needs to pick up
> a static copy of libgcc, including EH. Since we're building the C library,
> glibc uses -nostdlib and links everything it needs explicitly. That means
> it needs to know whether libgcc_eh.a is available.
> The first thing I tried was to check for libgcc_eh.a during configure. That
> works, but my normal process is to build a --disable-shared toolchain, then
> glibc, then an --enable-shared toolchain. When I go back to my glibc
> working directory, I can't rebuild glibc any more. It only pulls in
> libgcc.a, and the EH routines are now missing.
> This patch half solves the problem, by creating a dummy libgcc_eh.a. A
> better solution IMO is to _always_ put the EH routines in libgcc_eh.a; I
> took a stab at that, but since it involves always linking in -lgcc_eh even
> when --disable-shared, I think it is too invasive for 4.0. And target
> headers do some very strange things with LIBGCC_SPEC.
> I think that making the set of libraries we provide more consistent across
> configurations is valuable, even if nothing will link this library by
> default. OK?
I don't like this. Either fix the problem or don't. And if the fix
is too invasive for 4.0 ... well too bad. This really only affects
glibc build, and only if you don't re-run configure. So, really, I
don't care at all.