This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux cross compiler...
- From: Greg Schafer <gschafer at zip dot com dot au>
- To: James E Wilson <wilson at specifix dot com>
- Cc: David Daney <ddaney at avtrex dot com>, gcc at gcc dot gnu dot org, binutils at sources dot redhat dot com
- Date: Fri, 29 Jul 2005 09:58:00 +1000
- Subject: Re: RFH: libgcc_s.so being unnecessarily linked for mipsel-linux cross compiler...
- References: <42E9368F.7000506@avtrex.com> <1122585976.23426.21.camel@aretha.corp.specifix.com>
On Thu, Jul 28, 2005 at 02:26:16PM -0700, James E Wilson wrote:
> It looks like you forgot to check the crt*.o files for undefined
> references.
>
> If the gcc/glibc toolchain wasn't built the optimal way, it is possible
> for crtbegin.o to have register_frame_info and deregister_frame_info
> calls for C++ EH unwinding which would require libgcc always.
>
> If built the optimal way, then the gcc/glibc toolchain will use an
> alternate method for C++ EH unwinding that does not require crtbegin.o
> support and hence does not require libgcc. This is why the x86 FC3 is
> OK.
>
> See the USE_PT_GNU_EH_FRAME stuff in gcc/crtstuff.c.
Jim, I'd be grateful if you could please clarify what you mean by the
"optimal way". I assume you mean whether the initial "bootstrap" cross
compiler was built against Glibc headers or not. ie:
Glibc headers ARE provided -> inhibit_libc NOT defined -> optimal
Glibc headers ARE NOT provided -> inhibit_libc IS defined -> suboptimal
It seems to me that most Glibc targets can be built either way, but some
need a little coaxing, Mips can certainly be built either way "out of the
box". AFAICT, IA64 is the only target that cannot be built without access to
the Glibc headers.
Clearly, optimal is best :-)
Thanks for any clarification.
Regards
Greg