Issue with dynamically loading the glibc library

[Joseph Lutz]

On our 32-bit embedded system we have been working through our year 2038 problems. In one place we are using python to dynamically load the glibc library and call the clock_settime() function. The call is not working for dates after 2038. I used strace to see what the kernel is receiving and am noticing that it is passing the time as if it were a 32-bit integer even though we are compiling with _TIME_BITS=64 set.
I dug into this more by creating a couple small C programs. One program dynamically loads and then calls the clock_settime() function in glibc. This program passes the time as a 64-bit integer to the kernel and sets the system date correctly. The other program dynamically loads glibc and then used that to call the clock_settime() function. This program returns an error and dose not set the system date. It passes the time_t value as if it were a 32-bit integer.

The version of glibc we are compiling is 2.35 and readelf shows the following:
$ readelf --dyn-syms -W ./libc.so | grep clock_settime
   150: 000aed88   292 FUNC    GLOBAL DEFAULT   13 __clock_settime64@@GLIBC_2.34
  1055: 000aeeac    44 FUNC    GLOBAL DEFAULT   13 clock_settime@GLIBC_2.4
  1056: 000aeeac    44 FUNC    GLOBAL DEFAULT   13 clock_settime@@GLIBC_2.17

It is my guess that the default ABI (clock_settime@@GLIBC_2.17) treats the time_t as if it were a 32-bit integer.
If my guess is correct is there a way that the clock_settime@@GLIBC_2.17 can be removed or the default be changed to the clock_settime@GLIBC_2.4? I am not even cretin either of those two ideas are good. Is there a better way to have python call the clock_settime() function?


Joseph Lutz