On Mon, 2013-09-23 at 16:26 +0100, Marcus Shawcroft wrote: > On 4 June 2013 20:49, Steve Ellcey <sell...@mips.com> wrote: > > This patch allows me to build libgfortran for a cross-compiling toolchain > > using newlib. Currently the checks done by AC_CHECK_FUNCS_ONCE fail with > > my toolchain because the compile/link fails due to the configure script not > > using the needed linker script in the link command. The check for > > with_newlib > > is how libjava deals with the problem and it fixes my build problems. > > > > My only concern is defining HAVE_STRTOLD, strtold exists in my newlib but > > I am not sure if that is true for all newlib builds. I didn't see any > > flags that I could easily use to check for long double support in the > > libgfortran configure.ac, but it seems to assume that the type exists. > > > > OK to checkin? > > This patch breaks systems where long double is wider than double. The > newlib implementation provides strtold for systems where double is as > wide as long double but not on systems where long double is wider. > > I don;t see any issues with AC_CHECK_FUNC_ONCE when cross configuring > aarch64 toolchains but I would have thought that fixing the link test > issue you encountered would be preferable to hard coding assumptions > in the configure script? > > Cheers > /Marcus
AC_CHECK_FUNC_ONCE may work for aarch64 but I don't think there is anyway to make it work generally for all platforms. In the libjava configure.ac file is the comments: [dnl Botheration. Now we've got to detect the exception model. dnl Link tests against libgcc.a are problematic since -- at least dnl as of this writing -- we've not been given proper -L bits for dnl single-tree newlib and libgloss. and: # We are being configured with a cross compiler. AC_REPLACE_FUNCS # may not work correctly, because the compiler may not be able to # link executables. The libstdc++ configure has comments to the same effect: # This lets us hard-code the functionality we know we'll have in the cross # target environment. "Let" is a sugar-coated word placed on an especially # dull and tedious hack, actually. # # Here's why GLIBCXX_CHECK_MATH_SUPPORT, and other autoconf macros # that involve linking, can't be used: # "cannot open sim-crt0.o" # "cannot open crt0.o" # etc. All this is because there currently exists no unified, consistent # way for top level CC information to be passed down to target directories: # newlib includes, newlib linking info, libgloss versus newlib crt0.o, etc. # When all of that is done, all of this hokey, excessive AC_DEFINE junk for # crosses can be removed. The libstdc++ configure file has something that looks like it might be intended to address the problem of long double support (long_double_math_on_this_cpu) but I don't see where that variable is ever set in any configure file even though it is used in the libstdc++ configure file. Steve Ellcey sell...@mips.com
