Re: AC_SYS_LARGEFILE_REQUIRED vs. AC_SYS_YEAR2038_REQUIRED on MSVC

[Paul Eggert]

On 2023-04-16 08:18, Bruno Haible wrote:

Yes. Here are adjusted patches.


Thanks, I installed those.

Re: AC_SYS_LARGEFILE_REQUIRED vs. AC_SYS_YEAR2038_REQUIRED on MSVC

[Adhemerval Zanella]

> On 16 Apr 2023, at 12:28, Bruno Haible  wrote:
> 
> I presented the test results:
>>  - hello-3: no gnulib, just AC_SYS_LARGEFILE_REQUIRED
>>  - hello-4: no gnulib, just AC_SYS_YEAR2038_REQUIRED
>>  - testdir3: a gnulib testdir for the modules largefile-required stat
>>  - testdir4: a gnulib testdir for the modules year2038-required stat
>> 
>> mingw64  mingw32  msvc64  msvc32
>> 
>> hello-3OK   OK "support not detected" -> fail
>> hello-4OK   OK "support not detected" -> fail
>> testdir3   OK   OK   OK  OK
>> testdir4   OK   OK   OK  OK
> 
> Now, one could argue that in the above table the outcome should be:
> 
> mingw64  mingw32  msvc64  msvc32
> 
> hello-3OK   OK "support not detected" -> fail
> hello-4OK   OK   OK  OK
> testdir3   OK   OK   OK  OK
> testdir4   OK   OK   OK  OK
> 
> since in hello-4 the maintainer has only asked for year 2038
> support, not for large files support. And the dependency from year 2038
> support to large files support exists only in glibc (since the glibc
> developers found it pointless to add a 'struct stat' variant with
> 32-bit off_t and 64-bit time_t).

It is pointless indeed, it would require another 4 compat symbols with extra 
translation layer, further complexity for symbol redirection, and even more 
testing to check for any broken state (as we found while testing some some 
specific architectures).

Re: AC_SYS_LARGEFILE_REQUIRED vs. AC_SYS_YEAR2038_REQUIRED on MSVC

[Bruno Haible]

I presented the test results:
>   - hello-3: no gnulib, just AC_SYS_LARGEFILE_REQUIRED
>   - hello-4: no gnulib, just AC_SYS_YEAR2038_REQUIRED
>   - testdir3: a gnulib testdir for the modules largefile-required stat
>   - testdir4: a gnulib testdir for the modules year2038-required stat
> 
>  mingw64  mingw32  msvc64  msvc32
> 
> hello-3OK   OK "support not detected" -> fail
> hello-4OK   OK "support not detected" -> fail
> testdir3   OK   OK   OK  OK
> testdir4   OK   OK   OK  OK

Now, one could argue that in the above table the outcome should be:

 mingw64  mingw32  msvc64  msvc32

hello-3OK   OK "support not detected" -> fail
hello-4OK   OK   OK  OK
testdir3   OK   OK   OK  OK
testdir4   OK   OK   OK  OK

since in hello-4 the maintainer has only asked for year 2038
support, not for large files support. And the dependency from year 2038
support to large files support exists only in glibc (since the glibc
developers found it pointless to add a 'struct stat' variant with
32-bit off_t and 64-bit time_t). Whereas MSVC has all 4 possible
variants for 'struct stat' (32/64-bit off_t and 32/64-bit time_t) [1].

But for this improvement, the Autoconf code of AC_SYS_YEAR2038_REQUIRED
would need to distinguish glibc systems from MSVC systems in one way or
the other. You said that you don't like the use AC_CANONICAL_HOST here;
on the other hand, an extra compiler or preprocessor invocation is
pointless if AC_CANONICAL_HOST has already been used.

Anyway, this is low priority for me, since MSVC support without gnulib
is not going to work well in so many aspects anyway.

Bruno

[1] 
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/stat-functions?view=msvc-170

Re: AC_SYS_LARGEFILE_REQUIRED vs. AC_SYS_YEAR2038_REQUIRED on MSVC

[Paul Eggert]

Thanks for looking into this.


+[AC_REQUIRE([AC_CANONICAL_HOST])
Is there some way we can do this without requiring AC_CANONICAL_HOST? 
We're close to a release for Autoconf, and requiring this at the last 
minute for AC_SYS_LARGEFILE is a bit of a stretch.


That is, instead of AS_CASE([$host_os], ...) can  we use 
AC_PREPROC_IFELSE with the appropriate C preprocessor tests? Or perhaps 
do the AC_REQUIRE only if gl_LARGEFILE is defined?

Re: AC_SYS_LARGEFILE_REQUIRED vs. AC_SYS_YEAR2038_REQUIRED on MSVC

[Bruno Haible]

I wrote:
> > Also, maybe it is necessary to distinguish the use of these two Autoconf
> > macros without and with Gnulib?
> >- Without Gnulib, they could both fail on MSVC.
> >- But with Gnulib, they should both succeed on MSVC.

but I was wrong regarding the expected outcome. The correct expectations are:

* For AC_SYS_LARGEFILE_REQUIRED:
  - With mingw:
  checking for <$CC> option to enable large file support... 
-D_FILE_OFFSET_BITS=64
  - With MSVC:
Without gnulib:
  checking for <$CC> option to enable large file support... support not 
detected
  and configure fails.
With gnulib:
  checking for <$CC> option to enable large file support... supported 
through gnulib

* For AC_SYS_YEAR2038_REQUIRED:
  time_t is already 64-bits on 64-bit mingw and on MSVC.
  So:
- with 32-bit mingw:
checking for <$CC> option to enable timestamps after Jan 2038... 
-D__MINGW_USE_VC2005_COMPAT
- with 64-bit mingw or MSVC:
checking for <$CC> option to enable timestamps after Jan 2038... none 
needed
  Configuration will not fail due to time_t.
  But configuration will fail with MSVC and without gnulib (see above).

Paul Eggert wrote:
> I don't use MSVC.

I dug a bit and came up with the attached two proposed patches, one for
Autoconf and one for Gnulib.

In combination with Gnulib, they achieve the expected outcome described
above. I.e. no configure failure in any of the 4 native Windows platforms.

Without Gnulib, I believe (but haven't tested) that the outcome is as
described above as well.

> > Also, maybe it is necessary to distinguish the use of these two Autoconf
> > macros without and with Gnulib?
> >- Without Gnulib, they could both fail on MSVC.
> >- But with Gnulib, they should both succeed on MSVC.
> 
> That is what would happen if we could write a gl_YEAR2038, I assume.

It turned out that a gl_YEAR2038 is not needed, because native Windows
is not a special case regarding the time_t size: in 3 cases the result is
"none needed", in 1 case the result is a C macro definition that gets
put into config.h. And this C macro definition is effective without
any further help from Gnulib.

Bruno

>From 2e2597af089f5848f224964c7000dea44d8b0107 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sun, 16 Apr 2023 01:24:34 +0200
Subject: [PATCH] AC_SYS_YEAR2038_REQUIRED: Fix configure failure with MSVC.

* lib/autoconf/specific.m4 (_AC_SYS_LARGEFILE_PROBE): Require AC_CANONICAL_HOST.
Distinguish the results "support not detected" and "supported through gnulib".
If the result is "supported through gnulib", don't fail.
---
 lib/autoconf/specific.m4 | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/lib/autoconf/specific.m4 b/lib/autoconf/specific.m4
index 3bf1a0ed..e74d2296 100644
--- a/lib/autoconf/specific.m4
+++ b/lib/autoconf/specific.m4
@@ -310,7 +310,8 @@ m4_define([_AC_SYS_LARGEFILE_OPTIONS], m4_normalize(
 # If you change this macro you may also need to change
 # _AC_SYS_LARGEFILE_OPTIONS.
 AC_DEFUN([_AC_SYS_LARGEFILE_PROBE],
-[AC_CACHE_CHECK([for $CC option to enable large file support],
+[AC_REQUIRE([AC_CANONICAL_HOST])
+AC_CACHE_CHECK([for $CC option to enable large file support],
   [ac_cv_sys_largefile_opts],
   [ac_save_CC="$CC"
   ac_opt_found=no
@@ -323,11 +324,23 @@ AC_DEFUN([_AC_SYS_LARGEFILE_PROBE],
 test $ac_opt_found = no || break
   done
   CC="$ac_save_CC"
+  dnl Gnulib implements large file support for native Windows, based on the
+  dnl variables WINDOWS_64_BIT_OFF_T, WINDOWS_64_BIT_ST_SIZE.
+  m4_ifdef([gl_LARGEFILE], [
+if test $ac_opt_found != yes; then
+  AS_CASE([$host_os],
+[mingw*],
+  [ac_cv_sys_largefile_opts="supported through gnulib"
+   ac_opt_found=yes]
+  )
+fi
+  ])
   test $ac_opt_found = yes || ac_cv_sys_largefile_opts="support not detected"])
 
 ac_have_largefile=yes
 AS_CASE([$ac_cv_sys_largefile_opts],
   ["none needed"], [],
+  ["supported through gnulib"], [],
   ["support not detected"],
 [ac_have_largefile=no
  AS_IF([test $ac_largefile_required,$ac_year2038_required != no,no],
-- 
2.34.1

>From 1f49c355984a5e2bb7f5f4af5ebdd657cadf1988 Mon Sep 17 00:00:00 2001
From: Bruno Haible 
Date: Sun, 16 Apr 2023 01:22:19 +0200
Subject: [PATCH] year2038-required: Fix configure failure with MSVC.

* m4/largefile.m4 (_AC_SYS_LARGEFILE_PROBE): Require AC_CANONICAL_HOST.
Distinguish the results "support not detected" and "supported through
gnulib". If the result is "supported through gnulib", don't fail.
---
 ChangeLog   |  7 +++
 m4/largefile.m4 | 15 ++-
 2 files changed, 21 insertions(+), 1 deletion(-)

diff --git a/ChangeLog b/ChangeLog
index 0e5a94eab1..d4ea19e445 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,10 @@
+2023-04-15  Bruno Haible  
+
+	year2038-required: Fix configure failure with MSVC.
+	* m4/largefile.m4 (_AC_SYS_LARGEFILE_PROBE): Require AC_CANONICAL_HOST.
+	Distinguish the results "support not detected" and 

Re: AC_SYS_LARGEFILE_REQUIRED vs. AC_SYS_YEAR2038_REQUIRED on MSVC

[Paul Eggert]

On 4/14/23 09:02, Bruno Haible wrote:

On the other hand, when I create a gnulib testdir with an
AC_SYS_YEAR2038_REQUIRED invocation:
   ./gnulib-tool --create-testdir --dir=... --single-configure 
year2038-required stat
it fails during the configure stage on MSVC (both 64-bit and 32-bit):


It sounds like we need a gl_YEAR2038 to go along with the existing 
gl_LARGEFILE. However, I don't know what should be in gl_YEAR2038 as I 
don't use MSVC.




Also, maybe it is necessary to distinguish the use of these two Autoconf
macros without and with Gnulib?
   - Without Gnulib, they could both fail on MSVC.
   - But with Gnulib, they should both succeed on MSVC.


That is what would happen if we could write a gl_YEAR2038, I assume.