¿Por qué un Perl sin subprocesos no usa el tipo off64_t en comparación con uno habilitado para subprocesos?

Question

Mi tarea inicial era instalar mod_perl 2.0.6 + Apache 2.2.22. El proceso se detuvo con muchos errores relacionados con off64_t al compilar mod_perl. Entonces, comencé a cavar más profundo. En primer lugar, he instalado dos nuevas instancias de Perl 5.8.9 (porque tendré que usar esta versión): una versión con subprocesos y una sin subprocesos (son idénticos, solo difieren usethreads). Intentando reproducir el mismo usando el Perl enhebrado terminado con éxito y sin errores off64_t en absoluto.
La conclusión es obvia: Perl con rosca proporciona el necesario off64_t, el no roscado no.
Busca más lejos, han comparado config.h (de core/<arch>/CORE) de ambos Perl'es, y en la línea 3671 I puede ver esto (en el Perl no roscada):

/* HAS_OFF64_T: 
    *  This symbol will be defined if the C compiler supports off64_t. 
    */ 
    /*#define  HAS_OFF64_T   /**/ 

y en los hilos habilitado Perl:

#define HAS_OFF64_T   /**/ 

perl -V para ambos casos Perl anuncia ccflags ='... -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ...' opciones del compilador como usados.

Según tengo entendido, off64_t se utiliza para archivos de gran tamaño y no está relacionado con los hilos. He encontrado esta información sobre off_t y off64_t:

Si la fuente se compila con _FILE_OFFSET_BITS = 64 este tipo (es decir off_t) se sustituye de forma transparente por off64_t.

Poco: Hay 2 idénticos Perl construye con una única diferencia: el parámetro de configuración usethreads. Threaded Perl habilita off64_t, uno sin hilos no.

Mi pregunta es: por qué sucede esto y cómo los hilos se conectan a esta off64_t tipo de datos que se debe utilizar para archivos de gran tamaño, no para las discusiones?

Info: Arch Linux SO de 32 bits (kernel 2.6.33), gcc 4.5.0, 2.11.1 libc, Perl estándar 5.8.9

Notas: off64_t se procesa en Configure en la línea 15526, una simple try.c se genera e intenta compilarse. La pregunta es por qué el Perl sin subprocesos no puede compilarlo mientras que Perl con subprocesos puede hacerlo.

Answer 1

No estoy seguro de si responder mi propia pregunta es un comportamiento aceptado, pero mientras buscaba la solución y no solo esperaba a que alguien más hiciera mi tarea , creo que sería útil para otras personas leyendo esto.

En breve, la respuesta a mi pregunta es el -D_GNU_SOURCE indicador del compilador gcc y parece que los subprocesos no tienen nada en común con este tipo off64_t.

Parece que cuando -Dusethreads se utiliza para Configure, hints/linux.sh se utiliza y el siguiente código se ejecuta:

case "$usethreads" in 
$define|true|[yY]*) 
    ccflags="-D_REENTRANT -D_GNU_SOURCE -DTHREADS_HAVE_PIDS $ccflags" 

entonces el código se compila con _GNU_SOURCE definido, lo que permite una gran cantidad de cosas que se utilizará (como se responde en este hilo: What does “#define _GNU_SOURCE” imply?).

Cuando Perl se crea sin soporte de hilos, estos indicadores se omiten y muchos de los bits de los archivos de encabezado permanecen comentados.
Parece que el Perl no se ve afectado por esto. Incluso las versiones anteriores de Apache no lo eran, pero Apache 2.2+ comenzó a usar el código habilitado por _GNU_SOURCE y la construcción de mod_perl no es tan sencilla como antes.

No sé quién debería tomar nota de esto. Tal vez los mantenedores centrales de Perl, tal vez mantenedores de Apache, tal vez nadie y es solo mi caso particular o problemas con el compilador.

Conclusión: cuando la construcción no roscado con Perl el _GNU_SOURCE no se utiliza, como resultado de Perl .h archivos tienen una gran cantidad de comentarios #define s y la creación de fuentes de mod_perl contra el Apache 2.2 + falla. Se debe agregar un -Accflags='-D_GNU_SOURCE' adicional al construir Perl.

Otras respuestas son bienvenidas también. Tal vez estoy equivocado o simplemente estoy viendo la parte superior del iceberg.