Fue un error heredado en la implementación de la extensibilidad de glibc para la definición de struct stat antes de que se pensaran en mejores mecanismos (redireccionamiento de símbolos o control de versiones). Las definiciones de las funciones de la familia stat en libc_nonshared.a hacen que la versión de la estructura se enlace en el momento del enlace, y las definiciones allí llaman a las funciones de la __xstat en la libc compartida real, que toman un argumento adicional que indica la estructura deseada versión. Esta implementación no cumple con el estándar ya que cada biblioteca compartida termina obteniendo su propia copia de las funciones de la familia stat con sus propias direcciones, rompiendo el requisito de que los punteros a la misma función se evalúen de la misma manera.

Aquí está el problema. Hace mucho tiempo, los miembros de la struct stat tenían tamaños diferentes a los que tienen hoy. En particular:

uid_t tenía 2 bytes (aunque creo que este se solucionó en la transición de libc5 a glibc)
gid_t era de 2 bytes
off_t tenía 4 bytes
blkcnt_t tenía 4 bytes
time_t era de 4 bytes

además, timespec no se usó en absoluto y no había espacio para la precisión de nanosegundos.

Así que todo esto tuvo que cambiar. La única solución real fue hacer diferentes versiones de la llamada al sistema stat() y la función de biblioteca y obtener la versión contra la que compiló. Es decir, el archivo .a coincide con los archivos de encabezado. Estas cosas no cambiaron todas a la vez, pero creo que ya hemos terminado de cambiarlas.

Realmente no puedes resolver esto con una macro porque el nombre de la estructura es el mismo que el nombre de la función; e inline no estaba obligado a existir al principio, por lo que glibc no podía exigir que todos lo usaran.

Recuerdo que solía haber esta cosa O_LARGEFILE para decir que podía manejar archivos de más de 4 GB; de lo contrario, las cosas simplemente no funcionarían. También teníamos que definir cosas como _LARGEFILE_SOURCE y _LARGEFILE64_SOURCE , pero ahora todo se maneja automáticamente. En el pasado, si aún no estaba listo para admitir archivos grandes, no los definió y no obtuvo la versión de 64 bits de la estructura stat ; y también trabajó en versiones anteriores del kernel que carecían de las nuevas llamadas al sistema. no he comprobado; es posible que la compilación de 32 bits aún no los defina automáticamente, pero la de 64 bits siempre lo hace.

Así que probablemente pienses; está bien, está bien, ¿simplemente no hagas franken-compile cosas? Simplemente construya todo lo que entra en el ejecutable final con la misma versión de glibc y opción de archivo grande. ¿Alguna vez usó complementos como complementos de navegador? Esos están prácticamente garantizados para ser compilados en diferentes lugares con diferentes compiladores y versiones y opciones de glibc; y esto no requería que actualizara su navegador y reemplazara todos sus complementos al mismo tiempo.