Le 2025-01-03 17:43, Helge Deller a écrit :
On 1/3/25 15:55, p...@debian.org wrote:You were right about the gmtime() function being involved. Itappears that on powerpc and hppa it returns 01/01/1970. I've set up a reproducer (attached).That's what I needed. Thanks!On powerpc / hppa: $ gfortran -g -o test_gmtime test_gmtime.F90 $ ./test_gmtime time8: 1735915109 Year: 1970 Month: 1 Day: 1 Hour: 0 Minute: 0 Second: 0 On amd64: $ gfortran -g -o test_gmtime test_gmtime.F90 0 ;) pini@pinibrem14:~/tmp/h5gmtime $ ./test_gmtime time8: 1735915041 Year: 2025 Month: 1 Day: 3 Hour: 14 Minute: 37 Second: 21 I don't know how to solve this yet.Ok, I know how to fix it: In your fortran example, replace FUNCTION gmtime_c(stdtime_t) BIND(C, NAME='gmtime') by: FUNCTION gmtime_c(stdtime_t) BIND(C, NAME='__gmtime64') On 32-bit platforms, glibc provides "gmtime" for 32-bit time_t, and __gmtime64 for 64-bit time_t. At compile time depending on defines, one or the other is used. Is it possible to detect during config time, if that function is exported by glibc, and then use it if it's available?
I'm not sure that would be the correct solution. I think there is now an inconsistency between gcc and gfortran on hppa and powerpc, the former using __gmtime64 as the default for gmtime, and the latter sticking to its legacy 32-bit implementation.
This problem doesn't exist on litte-endian 32-bit architectures. Best, _g.
signature.asc
Description: OpenPGP digital signature
