This patch:
http://gcc.gnu.org/ml/fortran/2013-06/msg00038.html
... breaks libgfortran configure against newlib.
The solution implemented hard wires an assumption in
libgfortran/configure.ac that newlib provides strtold(). This
assumption is not correct, newlib only provides an implementation of
strtold on systems where sizeof(long double) == sizeof(double). This
manifests as a regression when trying to build a cross aarch64 bare
metal toolchain with fortran enabled.
The attached patch tightens the condition introduced in the earlier
patch such that we continue to call AC_CHECK_FUNCS_ONCE unless we know
that link tests are not possible, in which case we fall back to the
existing broken assumption.
I'm in two minds about whether further sticky tape of this form is the
right approach or whether the original patch should be reverted until a
proper fix that does not regress the tree can be found.
Thoughts?
2013-09-26 Marcus Shawcroft <marcus.shawcr...@arm.com>
* configure.ac (AC_CHECK_FUNCS_ONCE): Make if statement
dependent on gcc_no_link.
Cheers
/Marcusdiff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 4609eba..411ab38 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -261,7 +261,7 @@ GCC_HEADER_STDINT(gstdint.h)
AC_CHECK_MEMBERS([struct stat.st_blksize, struct stat.st_blocks, struct
stat.st_rdev])
# Check for library functions.
-if test "x${with_newlib}" = "xyes"; then
+if test "x${with_newlib}" = "xyes" -a "x${gcc_no_link}" = "xyes" ; then
# 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.
