Bug#1091911: hdf5 FTBFS on hppa

[pini]

Le 2025-01-02 23:30, p...@debian.org a écrit :

Le 2025-01-02 14:04, Helge Deller a écrit :

Package: hdf5
Version: 1.14.5+repack-2
Tags: ftbfs
Usertags: hppa

The fortran test is the only one which fails on hppa:
https://buildd.debian.org/status/fetch.php?pkg=hdf5&arch=hppa&ver=1.14.5%2Brepack-2&stamp=1735623616&raw=0


 h5ovisit_f 1 FAILED
 h5ovisit_f  1a FAILED
 h5ovisit_f 2 FAILED
 h5ovisit_f 2a FAILED
 h5ovisit_by_name_f 1 FAILED
 h5ovisit_by_name_f 1a FAILED


Which ones exactly can be seen with this patch:

Testing object functions PASSED Testing object visiting functions *FAILED*

[skipped]

It seems the gmtime() function is involved.
Could it be caused by the fact that time_t is now 64bit on hppa.
Note: hppa is a big-endian 32-bit userspace platform.

I tried to debug this, but I'm lacking too much fortran or hdf knowledge.

Same failure on powerpc which is big-endian 32-bit as well.

I've set up a reproducer (attached).

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.



Best,
module time_module
  use, intrinsic :: iso_c_binding
  implicit none

  type :: tm_type
    integer(c_int) :: tm_sec   ! seconds after the minute [0-60]
    integer(c_int) :: tm_min   ! minutes after the hour [0-59]
    integer(c_int) :: tm_hour  ! hours since midnight [0-23]
    integer(c_int) :: tm_mday  ! day of the month [1-31]
    integer(c_int) :: tm_mon   ! months since January [0-11]
    integer(c_int) :: tm_year  ! years since 1900
    integer(c_int) :: tm_wday  ! days since Sunday [0-6]
    integer(c_int) :: tm_yday  ! days since January 1 [0-365]
    integer(c_int) :: tm_isdst ! Daylight Saving Time flag
  end type tm_type

  INTERFACE
    FUNCTION gmtime_c(stdtime_t) BIND(C, NAME='gmtime')
      IMPORT :: C_PTR
      IMPLICIT NONE
      INTEGER(8) :: stdtime_t
      TYPE(C_PTR) :: gmtime_c
    END FUNCTION gmtime_c
  END INTERFACE

contains

  subroutine get_gmtime(time, tm)
    use, intrinsic :: iso_c_binding
    implicit none
    integer(8), intent(in) :: time
    type(tm_type), intent(out) :: tm
    type(c_ptr) :: tm_ptr
    type(tm_type), pointer :: tm_p

    tm_ptr = gmtime_c(time)
    if (c_associated(tm_ptr)) then
      call c_f_pointer(tm_ptr, tm_p)
      tm = tm_p
    else
      print *, "Error: gmtime_c() returned a null pointer."
    end if
  end subroutine get_gmtime

end module time_module

program test_gmtime
  use time_module
  use, intrinsic :: iso_c_binding
  implicit none
  integer(8) :: current_time
  type(tm_type) :: tm

  current_time = time8()
  call get_gmtime(current_time, tm)

  print *, "time8: ", current_time
  print *, "Year: ", tm%tm_year + 1900
  print *, "Month: ", tm%tm_mon + 1
  print *, "Day: ", tm%tm_mday
  print *, "Hour: ", tm%tm_hour
  print *, "Minute: ", tm%tm_min
  print *, "Second: ", tm%tm_sec

end program test_gmtime

You were right about the gmtime() function being involved. It appears that on powerpc and hppa it returns 01/01/1970. Any chance you could test it on bookworm, to check if this could be related to the 64-bit time_t transition?

signature.asc
Description: OpenPGP digital signature