| Message ID | 9537bcb6-1a09-4bb8-adec-3932a1bfa333@BAMAIL02.ba.imgtec.org |
|---|---|
| State | New |
| Headers | show |
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
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
On 23/09/13 18:43, Steve Ellcey wrote: > 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: > I think it would be preferable to check whether link tests do something sane and only fall back to hard coding choices when that is not the case. As you've currently written things we do it the other way around. Historically that's caused problems as newlib has evolved.
diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac index 7d97fed..4a00470 100644 --- a/libgfortran/configure.ac +++ b/libgfortran/configure.ac @@ -261,13 +261,27 @@ GCC_HEADER_STDINT(gstdint.h) AC_CHECK_MEMBERS([struct stat.st_blksize, struct stat.st_blocks, struct stat.st_rdev]) # Check for library functions. -AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \ -ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \ -alarm access fork execl wait setmode execve pipe dup2 close \ -strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \ -getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \ -readlink getgid getpid getppid getuid geteuid umask getegid \ -secure_getenv __secure_getenv) +if test "x${with_newlib}" = "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. + AC_DEFINE(HAVE_MKSTEMP, 1, [Define if you have mkstemp.]) + AC_DEFINE(HAVE_STRTOF, 1, [Define if you have strtof.]) + AC_DEFINE(HAVE_STRTOLD, 1, [Define if you have strtold.]) + AC_DEFINE(HAVE_SNPRINTF, 1, [Define if you have snprintf.]) + AC_DEFINE(HAVE_STRCASESTR, 1, [Define if you have strcasestr.]) + AC_DEFINE(HAVE_VSNPRINTF, 1, [Define if you have vsnprintf.]) + AC_DEFINE(HAVE_LOCALTIME_R, 1, [Define if you have localtime_r.]) + AC_DEFINE(HAVE_GMTIME_R, 1, [Define if you have gmtime_r.]) +else + AC_CHECK_FUNCS_ONCE(getrusage times mkstemp strtof strtold snprintf \ + ftruncate chsize chdir getlogin gethostname kill link symlink sleep ttyname \ + alarm access fork execl wait setmode execve pipe dup2 close \ + strcasestr getrlimit gettimeofday stat fstat lstat getpwuid vsnprintf dup \ + getcwd localtime_r gmtime_r getpwuid_r ttyname_r clock_gettime \ + readlink getgid getpid getppid getuid geteuid umask getegid \ + secure_getenv __secure_getenv) +fi # Check strerror_r, cannot be above as versions with two and three arguments exist LIBGFOR_CHECK_STRERROR_R