Question

My initial task was to install mod_perl 2.0.6 + Apache 2.2.22.
The process stopped with a lot of errors related to off64_t when compiling mod_perl. So, I started to dig deeper. Firstly, I have installed two new instances of Perl 5.8.9 (because I’ll have to use this version): a threaded version and a not-threaded one (they are identical, only usethreads differs). Trying to reproduce the same using the threaded Perl finished with success and no off64_t errors at all.
The conclusion is obvious: threaded Perl provides the neccessary off64_t, the non-threaded one doesn’t.
Searching further, I have compared config.h (from core/<arch>/CORE) of both Perl’es, and at the line 3671 I can see this (in the non-threaded Perl):

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

and in the threads-enabled Perl:

    #define HAS_OFF64_T            /**/

perl -V for both Perl instances reports ccflags ='... -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ...' as used compiler flags.

As I understand, off64_t is used for large files and isn’t related to threads. I found this information about off_t and off64_t:

If the source is compiled with _FILE_OFFSET_BITS = 64 this type (i.e. off_t) is transparently replaced by off64_t.

Shortly: There are 2 identical Perl builds with a single difference: the usethreads configure parameter. Threaded Perl enables off64_t, non-threaded one doesn’t.

My question is: Why does this happen and how threads are connected to this off64_t data type that should be used for large files, not for threads ?

Info: Arch Linux OS 32-bit (kernel 2.6.33), gcc 4.5.0, libc 2.11.1, standard Perl 5.8.9

Notes: off64_t is processed in Configure at line 15526, a simple try.c is generated and tried to be compiled. The question is why the not-threaded Perl cannot compile it while threaded Perl can.

Answer 1

I’m not sure if answering my own question is an accepted behaviour, but while I was searching for the solution and not just waiting for someone else to do my homework, I think it will be useful for other people reading this.

Shortly, the answer to my question is the -D_GNU_SOURCE gcc compiler flag and it seems threads have nothing in common with this off64_t type.

It appears that when -Dusethreads is used for Configure, hints/linux.sh is used and the following code is executed:

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

then the code is compiled with _GNU_SOURCE defined, which allows a lot of things to be used (like is answered in these thread: What does “#define _GNU_SOURCE” imply?).

When Perl is built without threads support, these flags are skipped and a lot of bits from header files remain commented.
It seems the Perl itself is not affected by this. Even older versions of Apache were not, but Apache 2.2+ started to use code which is enabled by _GNU_SOURCE and building mod_perl is not as straightforward as before.

I don’t know who should take a notice about this. Maybe core Perl maintainers themselves, maybe Apache maintainers, maybe no one and it’s just my particlar case or compiler issues.

Conclusion: when building not-threaded Perl the _GNU_SOURCE is not used, as a result Perl .h files have a lot of commented #defines and building mod_perl against the Apache 2.2+ sources fails. An additional -Accflags='-D_GNU_SOURCE' should be added when building Perl.

Other answers are welcome too. Maybe I’m wrong or I’m just seeing the top of the iceberg.