On Thu, 2013-10-24 at 15:53 +0100, Marcus Shawcroft wrote: > Steve, > > Can your build be fixed allowing us to back out: > http://gcc.gnu.org/ml/fortran/2013-06/msg00038.html > > ? > > 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 sell...@mips.com
