This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib
- From: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- To: Steve Ellcey <sellcey at mips dot com>
- Cc: Mike Stump <mikestump at comcast dot net>, Tobias Burnus <burnus at net-b dot de>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, "fortran at gcc dot gnu dot org" <fortran at gcc dot gnu dot org>, Richard Earnshaw <Richard dot Earnshaw at arm dot com>
- Date: Wed, 6 Nov 2013 17:32:40 +0000
- Subject: Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib
- Authentication-results: sourceware.org; auth=none
- References: <52443AFE dot 5050802 at arm dot com> <1380298134 dot 5988 dot 61 dot camel at ubuntu-sellcey> <52497156 dot 5010203 at arm dot com> <524AB4AD dot 6070508 at arm dot com> <CAFqB+PxJR53JGV3f8dy7SNRHbdVMc0aqAC5ruFC6S0WXtksE5w at mail dot gmail dot com> <525DA2D7 dot 5080509 at net-b dot de> <A7ECA8A4-5136-471E-A5E2-89D7B9977C9D at comcast dot net> <CAFqB+Pwx+N0VcFQaUpc2J6Wz5r6GwKYgDQnPMg2vvGHE++srDw at mail dot gmail dot com> <1382633270 dot 2558 dot 104 dot camel at ubuntu-sellcey>
On 24 October 2013 17:47, Steve Ellcey <sellcey@mips.com> wrote:
> I am not sure how we would fix the build issue to allow us to not
> hardcode the newlib configure details into the libgfortran configure
> script. The linker script that needs to be used to get a good link is
> different depending on what options one is compiling with on a multilib
> MIPS system and I have no idea on how one could create (or use) a dummy
> linker script. Ideally, I think we would want a check that does not
> depend on linking at all.
>
> Note that this problem is not just in libgfortran, it affects libstdc++
> and libjava too and those configure scripts also have hardcoded the
> newlib assumptions. The only difference between libgfortran and the
> other two libraries is that the newlib assumptions for libgfortran are
> not static like they are for libstdc++ and libjava. They vary (for one
> function) based on whether or not long double is supported.
Exactly, hard wiring the newlib interface into the configury of other
libraries is questionable, but the patch applied to libgfortran goes
beyond hard wiring details of the interface, it hard wires incorrect
details of the interface when sizeof(long double) != sizeof(double).
The argument that the patch is OK because libjava and libstdc++ also
use this idiom, is also rather questionable, because the libgfortran
patch goes beyond the idiom used in those other libraries by hard
wiring an assumption that does not hold universally.
On that basis, I think the the libgfortran patch should be reverted
since it caused a regression.
/Marcus