linuxtimearmglibcyear2038

Do I have to re-compile glibc 2.34 itself for full 64-bit time_t support for 32-bit hardware?


My CPU is of type armhf, so 32-bit. I run Linux Kernel 5.4 on it (so it supports 64-bit time_t for 32-bit system). I compile programs against glibc 2.34 (so time_t can be explicitely set to be 64-bit instead of 32-bit).

Now I am trying to get this simple piece of code working (test.c).

#include <stdio.h>
#include <sys/stat.h>
#include <string.h>
#include <errno.h>

int main()
{
    int ret = 0;
    ret = lchmod ("/tmp/testme.file", 0755);
    printf("ret=%d; errno=%d, strerror=%s\n", ret, errno, strerror(errno));
    return 0;
}

(Cross-)Compile it like so:

arm-linux-gnueabihf-gcc -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 test.c -o test

To test the program I set my system date to 2084-01-01 (beyond year 2038 is important). Then I create a file by running touch /tmp/testme.file. This file gets a creation timestamp of 2084-01-01. Now when I run the above code ./test it gives me this error message:

ret=-1; errno=75, strerror=Value too large for defined data type

It seems Value too large for defined data type error happens because the function lchmod(...) cannot handle files with creation timestamps beyond year 2038.

Why is this? Is this a glibc bug or does the glibc 2.34 itself has to be re-compiled with additional CFLAGS -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64.

When I change lchmod(...) to chmod(...) it works.


Solution

  • This is indeed a glibc bug, you want a version that includes commit 118a2aee07f64d605b6668cbe195c1f44eac6be6. That is v2.36 or newer.