This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib
- From: Steve Ellcey <sellcey at mips dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail 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: Thu, 24 Oct 2013 09:47:50 -0700
- 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>
On Thu, 2013-10-24 at 15:53 +0100, Marcus Shawcroft wrote:
> Can your build be fixed allowing us to back out:
> I'd really like to make some progress on this, while my proposed patch
> does resolve the regression introduced by the above patch I am
> concerned that this is going in the wrong direction and that we
> should, as Mike suggests above fix the build issue such that autoconf
> behaves, rather than attempting to hardwire configure details of
> newlib into libgfortran...
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.
If we want to come up with a better solution it should be used for all
the libraries and not just for libgfortran.