This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
- From: Paolo Carlini <paolo dot carlini at oracle dot com>
- To: Ralf Wildenhues <Ralf dot Wildenhues at gmx dot de>, Matthias Klose <doko at ubuntu dot com>, Paolo Carlini <paolo dot carlini at oracle dot com>, "libstdc++ at gcc dot gnu dot org" <libstdc++ at gcc dot gnu dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>, Andrew Haley <aph at redhat dot com>, Jakub Jelinek <jakub at redhat dot com>, Alexandre Oliva <aoliva at redhat dot com>, Nathan Froyd <froydnj at codesourcery dot com>, GCC Patches <gcc-patches at gcc dot gnu dot org>, GCJ-patches <java-patches at gcc dot gnu dot org>
- Date: Mon, 16 Nov 2009 23:45:41 +0100
- Subject: Re: [ping2] Re: [ping] Re: [patch] PR40134, use a linker script on arm-linux to link with -lgcc_s -lgcc
- References: <4ABB30DE.6050502@redhat.com> <4ABB3BE6.4060800@ubuntu.com> <4ABB4C9B.3070200@redhat.com> <1255527525.4842.29.camel@e200601-lin.cambridge.arm.com> <4ADF0B67.9070505@ubuntu.com> <4AEA2FF1.6060508@ubuntu.com> <4AEA3318.6060607@oracle.com> <4AEF025A.5060403@ubuntu.com> <4AEF08BF.4020500@oracle.com> <4AFC5187.2010909@ubuntu.com> <20091116223035.GA12513@gmx.de>
Ralf Wildenhues wrote:
> What would you suggest as the algorithm to fix it in libtool?
> Mind you, I've probably forgotten parts of this, so please bear
> with me:
>
> Should libtool always reorder -lgcc_s before -lgcc if it sees
> (or is to emit) both? On all systems? If not, on which?
> Which of the two should it reorder, and where, if the two do
> not occur successively? What if another library dependency
> drags in one but not the other, and we already have seen one
> or both?
>
> FWIW, I never saw a workable approach fixing libtool only,
> nor understood how libtool could be fixed consistently.
>
If you are confident that *all* the linux targets at the moment are
fine, you can as well hardcode in the library configure that knowledge
and skip running the configure test for those. However, if you want to
put in place the looser configure check, you must be 100% sure that it
also works correctly on anything != linux, and that means, per Joseph'
comments, making sure those generic compiler bits about linking the
static libgcc are properly implemented. Either of those is fine with me.
Paolo