[patch, libgfortran, configure] Cross-compile support for libgfortran

[Steve Ellcey]

On Mon, 2013-09-23 at 16:26 +0100, Marcus Shawcroft wrote:
> On 4 June 2013 20:49, Steve Ellcey <sellcey@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
sellcey@mips.com