¿Es necesario volver a compilar glibc 2.34 en sí mismo para tener un soporte completo de time_t de 64 bits para hardware de 32 bits?
Mi CPU es de tipo armhf, por lo que es de 32 bits. Ejecuto Linux Kernel 5.4 en él (lo que significa que admite tiempo de 64 bits para un sistema de 32 bits). Compilo programas con glibc 2.34 (por lo que el tiempo puede establecerse explícitamente en 64 bits en lugar de 32 bits).
Ahora estoy intentando hacer que este simple fragmento de código funcione (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;
}
Compílalo de la siguiente manera:
arm-linux-gnueabihf-gcc -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64 test.c -o test
Para probar el programa, establezco la fecha del sistema en 2084-01-01 (más allá de 2038 es importante). Luego creo un archivo ejecutando touch /tmp/testme.file. Este archivo obtiene una marca de tiempo de creación de 2084-01-01. Ahora, cuando ejecuto el código anterior ./test, me muestra este mensaje de error:
ret=-1; errno=75, strerror=Value too large for defined data type
Parece que el error Value too large for defined data type ocurre porque la función lchmod(...) no puede manejar archivos con marcas de tiempo de creación más allá del año 2038.
¿Por qué sucede esto? ¿Es un error de glibc o la glibc 2.34 en sí misma debe recompilarse con las CFLAGS adicionales -D_FILE_OFFSET_BITS=64 -D_TIME_BITS=64.
Cuando cambio lchmod(...) a chmod(...), funciona.</errno.h></string.h></stdio.h>
davy.ai
El problema con la función
lchmod(...)que no puede manejar archivos con marcas de tiempo de creación más allá del año 2038 se debe a una limitación en la biblioteca glibc. Específicamente, está relacionado con la forma en que glibc maneja el tipo de datotime_t, que se utiliza típicamente para representar el tiempo en sistemas tipo Unix.En la mayoría de los sistemas tipo Unix, incluyendo Linux, el tipo de dato
time_tes un entero con signo de 32 bits que representa el número de segundos desde el inicio de Unix (1 de enero de 1970). Esto significa quetime_tsolo puede representar fechas hasta el 19 de enero de 2038, después de lo cual ocurrirá una desbordamiento y volverá a un valor negativo. Esto se conoce como el problema del año 2038.Para abordar este problema, las versiones más nuevas del kernel de Linux (incluido el Kernel 5.4) han agregado soporte para calendario de 64 bits, lo que permite que
time_tsea un entero de 64 bits en sistemas de 32 bits. Sin embargo, esto requiere que los programas se compilen con las banderas adecuadas (-D_TIME_BITS=64) para habilitar el uso detime_tde 64 bits.En el caso de la función
lchmod(...)parece que esta función no maneja adecuadamente las marcas de tiempo de 64 bits, incluso cuando el programa se compila con las banderas adecuadas. Esto probablemente sea un error en glibc en sí, que puede necesitar ser corregido en una versión futura.Mientras tanto, una solución alternativa es utilizar la función
chmod(...)en lugar delchmod(...), ya que esta función no parece tener la misma limitación.En resumen, el problema con
lchmod(...)que no puede manejar archivos con marcas de tiempo de creación más allá del año 2038 se debe a una limitación en glibc relacionada con el uso del tipo de datotime_t. Si bien las versiones más nuevas del kernel admiten calendario de 64 bits, esto puede no ser compatible correctamente con todas las funciones en glibc. Para solucionar este problema, puede ser necesario utilizar funciones alternativas o esperar a que se corrija en una versión futura de glibc.