Re: [Patch] Add to the libgfortran/newlib bodge to "detect" ftruncate support in ARM/AArch64/SH

[James Greenhalgh <james dot greenhalgh at arm dot com>]

On Fri, Aug 21, 2015 at 11:05:47AM +0100, James Greenhalgh wrote:
> On Thu, Aug 20, 2015 at 10:50:47AM +0100, Marcus Shawcroft wrote:
> > On 20 August 2015 at 09:31, James Greenhalgh <james.greenhalgh@arm.com> wrote:
> > >
> > > Hi,
> > >
> > > Steve's patch in 2013 [1] to fix the MIPS newlib/libgfortran build
> > > causes subtle issues for an ARM/AArch64 newlib/libgfortran build. The
> > > problem is that ARM/AArch64 (and SH) define a stub function for
> > > ftruncate, which we would previously have auto-detected, but which is not
> > > part of the hardwiring Steve added.
> > >
> > > Continuing the tradition of building bodge on bodge on bodge, this patch
> > > hardwires HAVE_FTRUNCATE on for ARM/AArch64/SH, which does fix the issue
> > > I was seeing.
> >
> > This is the second breakage I'm aware of due to the introduction of
> > this hardwire code, the first being related to strtold.  My
> > recollection is that it is only the mips target that requires the
> > newlib API hardwiring. Ideally we should rely only on the
> > AC_CHECK_FUNCS_ONCE probe code and avoid the hardwire entirely.
> >
> > Perhaps a better approach for trunk would be something along the lines of:
> >
> > case "${host}--x${with_newlib}" in
> > mips*--xyes)
> >   hardwire_newlib=1;;
> > esac
> > if test "${hardwire_newlib:-0}" -eq 1; then
> >   ... existing AC_DEFINES hardwire code
> > else
> >   ... existing AC_CHECK_FUNCS_ONCE probe code
> > fi
> >
> > In effect limiting the hardwire to just the target which is unable to
> > probe.  For backport to 4.9 and 5 I think James' more conservative
> > patch is probably more appropriate.
> >
> > What do folks think?
>
> (+CC fortran@gcc.gnu.org - who I should have CCed from the start).
>
> This runs in to issues with a newlib build [1] (newlib provides a 'kill'
> symbol for linking, but does not provide a declaration in signal.h, so
> we take a -Werror=implicit-function-declaration).

This is what the patch you suggested would look like.

I've sent a patch to the newlib list [1] which unconditionally declares
'kill'. With that in place, we can then autodetect the presence of the
functions newlib provides. I'd expect that you would need to apply that
newlib patch if you were testing this patch locally.

I've tested this with a build of arm-none-eabi and aarch64-none-elf to
check that I now get HAVE_FTRUNCATE defined, and that the build completes.

OK?

Thanks,
James

---
2015-08-25  James Greenhalgh  <james.greenhalgh@arm.com>

	* configure.ac: Auto-detect newlib function support unless we
	know there are issues when configuring for a host.
	* configure: Regenerate.

---
[1]: https://sourceware.org/ml/newlib/2015/msg00632.html

diff --git a/libgfortran/configure.ac b/libgfortran/configure.ac
index 35a8b39..1e9914c 100644
--- a/libgfortran/configure.ac
+++ b/libgfortran/configure.ac
@@ -273,8 +273,13 @@ GCC_HEADER_STDINT(gstdint.h)
 
 AC_CHECK_MEMBERS([struct stat.st_blksize, struct stat.st_blocks, struct stat.st_rdev])
 
+case "${host}--x${with_newlib}" in
+  mips*--xyes)
+    hardwire_newlib=1;;
+esac
+
 # Check for library functions.
-if test "x${with_newlib}" = "xyes"; then
+if test "${hardwire_newlib:-0}" -eq 1; 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.