Perché un Perl non-threadato non sta usando il tipo off64_t rispetto a uno abilitato per i thread?

Question

Il mio compito iniziale era installare mod_perl 2.0.6 + Apache 2.2.22.
Il processo si è interrotto con molti errori relativi a off64_t durante la compilazione di mod_perl. Così, ho iniziato a scavare più a fondo. In primo luogo, ho installato due nuove istanze di Perl 5.8.9 (perché dovrò usare questa versione): una versione con thread e una senza thread (sono identici, solo usethreads differisce). Cercando di riprodurre lo stesso utilizzando il thread Perl finito con successo e senza errori off64_t affatto.
La conclusione è ovvia: il Perl con thread fornisce il necessario off64_t, quello non threadato no.
Cercando ulteriormente, ho confrontato config.h (da core/<arch>/CORE) di entrambi Perl'es, e alla linea 3671 che può vedere questo (in Perl non filettata):

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

e nei fili abilitato Perl:

#define HAS_OFF64_T   /**/ 

perl -V per entrambe le istanze Perl riporta ccflags ='... -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ...' flag di compilazione ed usati.

Come ho capito, off64_t viene utilizzato per file di grandi dimensioni e non è correlato ai thread. Ho trovato questa informazioni su off_t e off64_t:

Se la sorgente viene compilato con _FILE_OFFSET_BITS = 64 questo tipo (cioè off_t) è trasparente sostituito da off64_t.

Poco: Ci sono 2 identici Perl costruisce con una sola differenza: il parametro usethreads configure. Il Perl filettato abilita off64_t, quello non a thread no.

La mia domanda è: Perché accade questo e come le discussioni sono collegati a questo tipo di dati off64_t che dovrebbe essere utilizzato per i file di grandi dimensioni, non per le discussioni?

Info: Arch Linux sistema operativo a 32-bit (kernel 2.6.33), gcc 4.5.0, libc 2.11.1, standard di Perl 5.8.9

Note: off64_t è trasformato in Configure alla linea 15526, un semplice try.c viene generato e provato a essere compilato. La domanda è: perché il Perl non-threadato non può compilarlo mentre è in grado di filtrare il Perl.

Answer 1

Non sono sicuro che rispondere alla mia domanda sia un comportamento accettato, ma mentre cercavo la soluzione e non aspettavo che qualcun altro facesse il mio lavoro , penso che sarà utile per altre persone leggendo questo

In breve, la risposta alla mia domanda è il flag del compilatore gcc -D_GNU_SOURCE e sembra che i thread non abbiano nulla in comune con questo tipo off64_t.

Sembra che quando -Dusethreads viene utilizzato per Configure, hints/linux.sh viene utilizzato e il seguente codice viene eseguito:

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

quindi il codice è stato compilato con _GNU_SOURCE definita, che permette un sacco di cose da utilizzare (come viene risposto in questi thread: What does “#define _GNU_SOURCE” imply?).

Quando Perl viene creato senza supporto per i thread, questi flag vengono saltati e molti bit dei file di intestazione rimangono commentati.
Sembra che il Perl stesso non sia influenzato da questo. Anche le versioni precedenti di Apache non lo erano, ma Apache 2.2+ ha iniziato a utilizzare il codice abilitato da _GNU_SOURCE e la costruzione di mod_perl non è così semplice come prima.

Non so chi dovrebbe prendere nota di questo. Forse i manutentori del Perl di per se stessi, forse i manutentori di Apache, forse nessuno ed è solo il mio caso di particlar o il problema del compilatore.

Conclusione: quando si costruisce non-thread Perl il _GNU_SOURCE non viene utilizzato, a seguito Perl .h file hanno un sacco di commentato #define s e la costruzione mod_perl contro fonti del Apache 2.2 + fallisce. Un ulteriore -Accflags='-D_GNU_SOURCE' dovrebbe essere aggiunto durante la creazione di Perl.

Altre risposte sono benvenute. Forse ho torto o sto vedendo la cima dell'iceberg .