This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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

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


   # 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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]