[Bug libfortran/114895] New: Build failure with !HAVE_WORKING_STAT

[Bug libfortran/114895] New: Build failure with !HAVE_WORKING_STAT

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

            Bug ID: 114895
           Summary: Build failure with !HAVE_WORKING_STAT
           Product: gcc
           Version: 14.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libfortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: rguenth at gcc dot gnu.org
  Target Milestone: ---

[31724s] libtool: compile: 
/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git9885/obj-x86_64-suse-linux/./gcc/xgcc
-B/home/abuild/rpmbuild/BUILD/gcc-14.0.1+git9885/obj-x86_64-suse-linux/./gcc/
-B/usr/x86_64-suse-linux/bin/ -B/usr/x86_64-suse-linux/lib/ -isystem
/usr/x86_64-suse-linux/include -isystem /usr/x86_64-suse-linux/sys-include
-DHAVE_CONFIG_H -I. -I../../../../libgfortran -iquote../../../../libgfortran/io
-I../../../../libgfortran/../gcc -I../../../../libgfortran/../gcc/config
-I../../.././gcc -I../../../../libgfortran/../libgcc -I../../libgcc
-I../../../../libgfortran/../libbacktrace -I../../libbacktrace
-I../libbacktrace -std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes
-Wold-style-definition -Wextra -Wwrite-strings
-Werror=implicit-function-declaration -Werror=vla -fcf-protection -mshstk
-fcx-fortran-rules -ffunction-sections -fdata-sections -g -O2 -funwind-tables
-fasynchronous-unwind-tables -fstack-clash-protection -Werror=return-type -m32
-MT unix.lo -MD -MP -MF .deps/unix.Tpo -c ../../../../libgfortran/io/unix.c 
-fPIC -DPIC -o .libs/unix.o
[31724s] ../../../../libgfortran/io/unix.c: In function ‘find_file’:
[31724s] ../../../../libgfortran/io/unix.c:1704:26: error: ‘id’ undeclared
(first use in this function)
[31724s]  1704 | # define FIND_FILE0_ARGS id, path
[31724s]       |                          ^~
[31724s] ../../../../libgfortran/io/unix.c:1778:30: note: in expansion of macro
‘FIND_FILE0_ARGS’
[31724s]  1778 |   u = find_file0 (unit_root, FIND_FILE0_ARGS);
[31724s]       |                              ^~~~~~~~~~~~~~~
[31724s] ../../../../libgfortran/io/unix.c:1704:26: note: each undeclared
identifier is reported only once for each function it appears in
[31724s]  1704 | # define FIND_FILE0_ARGS id, path
[31724s]       |                          ^~
[31724s] ../../../../libgfortran/io/unix.c:1778:30: note: in expansion of macro
‘FIND_FILE0_ARGS’
[31724s]  1778 |   u = find_file0 (unit_root, FIND_FILE0_ARGS);
[31724s]       |                              ^~~~~~~~~~~~~~~
[31724s] make[6]: *** [Makefile:6863: unix.lo] Error 1

which is because find_file does

#if defined(__MINGW32__) && !HAVE_WORKING_STAT
  id = id_from_path (path);
#endif

  RDLOCK (&unit_rwlock);
retry:
  u = find_file0 (unit_root, FIND_FILE0_ARGS);

so as long as __MINGW32__ is not defined this won't work.  The fix might
be to remove the __MINGW32__ part of the conditional.

(and no, I didn't yet know how we arrived at !HAVE_WORKING_STAT - this is on
x86_64 linux, but with a -j1 build - see
https://bugzilla.suse.com/show_bug.cgi?id=1223169)

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Richard Biener <rguenth at gcc dot gnu.org> ---
So since this is for the 32bit multilib and the test below doens't seem to
enforce LFS we get a large inode number in the build setup and fail the
stat(), mis-detecting the feature.

libgfortran configure.ac misses AC_SYS_LARGEFILE it seems.


dnl Check whether the st_ino and st_dev stat fields taken together uniquely
dnl identify the file within the system. This is should be true for POSIX
dnl systems; it is known to be false on mingw32.
AC_DEFUN([LIBGFOR_CHECK_WORKING_STAT], [
  AC_CACHE_CHECK([whether the target stat is reliable],
                  libgfor_cv_have_working_stat, [
  AC_RUN_IFELSE([AC_LANG_SOURCE([[
#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

int main ()
{ 
  FILE *f, *g;
  struct stat st1, st2;

  f = fopen ("foo", "w");
  g = fopen ("bar", "w");
  if (stat ("foo", &st1) != 0 || stat ("bar", &st2))
    return 1;
  if (st1.st_dev == st2.st_dev && st1.st_ino == st2.st_ino)
    return 1;
  fclose(f);
  fclose(g);
  return 0; 
}]])], libgfor_cv_have_working_stat=yes, libgfor_cv_have_working_stat=no, [
case "${target}" in
  *mingw*) libgfor_cv_have_working_stat=no ;;
  *) libgfor_cv_have_working_stat=yes;;
esac])])
if test x"$libgfor_cv_have_working_stat" = xyes; then
  AC_DEFINE(HAVE_WORKING_STAT, 1, [Define if target has a reliable stat.])
fi])

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #2 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, no, that's there.

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #3 from Richard Biener <rguenth at gcc dot gnu.org> ---
The logfile shows

[31010s] checking for special C compiler options needed for large files... no
[31010s] checking for _FILE_OFFSET_BITS value needed for large files... 64
...
[31035s] checking whether the target stat is reliable... no

so the individual test has to use -D_FILE_OFFSET_BITS=64?

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
That is really weird.
Because the
checking for _FILE_OFFSET_BITS value needed for large files... 64
test should add
#define _FILE_OFFSET_BITS 64
line to confdefs.h and I believe the working stat testing should use that:
  if test "$cross_compiling" = yes; then :

case "${target}" in
  *mingw*) libgfor_cv_have_working_stat=no ;;
  *) libgfor_cv_have_working_stat=yes;;
esac
else
  cat confdefs.h - <<_ACEOF >conftest.$ac_ext
/* end confdefs.h.  */

#include <stdio.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <unistd.h>

int main ()
{
  FILE *f, *g;
  struct stat st1, st2;

  f = fopen ("foo", "w");
  g = fopen ("bar", "w");
  if (stat ("foo", &st1) != 0 || stat ("bar", &st2))
    return 1;
  if (st1.st_dev == st2.st_dev && st1.st_ino == st2.st_ino)
    return 1;
  fclose(f);
  fclose(g);
  return 0;
}
_ACEOF

The cat should source in all of confdefs.h so far.

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Created attachment 58075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58075&action=edit
conftest.c

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I've hacked up my libgfortran/configure, added there sleep 60s after writing
conftest.c for working stat check, and then rm -f config.cache; ./config.status
--recheck in the
x86*/32/libgfortran directory and the above conftest.c is what I saw.

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #7 from Richard Biener <rguenth at gcc dot gnu.org> ---
So besides maybe no way to reproduce the failure the source still has the issue
described.

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #8 from Sam James <sjames at gcc dot gnu.org> ---
(In reply to Richard Biener from comment #7)
> So besides maybe no way to reproduce the failure the source still has the
> issue
> described.

Sorry, not following -- jakub's attached one has #define _FILE_OFFSET_BITS 64,
so we should be fine?

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
(In reply to Sam James from comment #8)
> (In reply to Richard Biener from comment #7)
> > So besides maybe no way to reproduce the failure the source still has the
> > issue
> > described.
> 
> Sorry, not following -- jakub's attached one has #define _FILE_OFFSET_BITS
> 64, so we should be fine?

Iff !HAVE_WORKING_STAT (for whatever reason) but also !defined(__MINGW32__)
then the source will fail to build.  It looks like the key is
!HAVE_WORKING_STAT, not sure why defined(__MINGW32__) is checked here.

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[sjames at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #10 from Sam James <sjames at gcc dot gnu.org> ---
Ah, sorry, you meant GCC sources, not configure test source. ack

[Bug libfortran/114895] Build failure with !HAVE_WORKING_STAT

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114895

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
So the trigger is Y2038, aka missing -D_TIME_BITS=64 - reproducible in a
qemu environment with -rtc base=2038-01-20T00:00:00