This is the mail archive of the
mailing list for the GCC project.
Re: [patch, libgfortran, configure] Cross-compile support for libgfortran
- From: Steve Ellcey <sellcey at mips dot com>
- To: Marcus Shawcroft <marcus dot shawcroft at gmail dot com>
- Cc: <burnus at net-b dot de>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>, <fortran at gcc dot gnu dot org>
- Date: Mon, 23 Sep 2013 10:43:19 -0700
- Subject: Re: [patch, libgfortran, configure] Cross-compile support for libgfortran
- Authentication-results: sourceware.org; auth=none
- References: <9537bcb6-1a09-4bb8-adec-3932a1bfa333 at BAMAIL02 dot ba dot imgtec dot org> <CAFqB+PwYPNEk2Q1ySBAuAcnrJiqOmAt36r_7Yr9Cp2o4u2ZzHA at mail dot gmail dot com>
On Mon, 2013-09-23 at 16:26 +0100, Marcus Shawcroft wrote:
> On 4 June 2013 20:49, Steve Ellcey <email@example.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?
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.
# 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++