This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [PATCH v2] Fix libgfortran cross compile configury w.r.t newlib

On Thu, 2013-10-24 at 15:53 +0100, Marcus Shawcroft wrote:

> Steve,
> 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...
> /Marcus

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.

Steve Ellcey

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]