On 24 October 2013 17:47, Steve Ellcey <sell...@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
