Why doesn't non-stream Perl use the off64_t type compared to a stream with stream support?

Question

My initial task was to install mod_perl 2.0.6 + Apache 2.2.22.
The process ended with a lot of errors related to off64_t when compiling mod_perl. So, I started digging deeper. First, I installed two new Perl 5.8.9 instances (because I have to use this version): the streaming version and the non-streaming version (they are identical, only usethreads is different). Trying to reproduce the same using streaming Perl with success and error-free off64_t .
The conclusion is obvious: streaming Perl contains the necessary off64_t , which is not threaded. Next, I compared config.h (from core/<arch>/CORE ) to both Perl'es, and on line 3671 I see this (in non-stream Perl):

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

and in Perl, supporting threads:

  #define HAS_OFF64_T /**/ 

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

As I understand it, off64_t used for large files and is not associated with streams. 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 with off64_t .

usethreads soon : There are two identical Perl assemblies with one difference: the usethreads configure parameter. Threaded Perl includes off64_t , and not without threading - no.

My question is: why is this happening and how are streams related to this off64_t data off64_t , which should be used for large files, not streams?

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

Notes: off64_t processed in Configure on line 15526, a simple try.c is created and tries to compile. The question is why non-streaming Perl cannot compile it while it can work with Perl.

Answer 1

I'm not sure that the answer to my own question is accepted behavior, but while I was looking for a solution, and not just expecting someone else to do my homework, I think it will be useful for other people reading this.

Soon, the answer to my question is the -D_GNU_SOURCE flag of the gcc compiler, and it seems that the threads have nothing to do with this type of off64_t .

It appears that when -Dusethreads used for Configure , hints/linux.sh 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 using _GNU_SOURCE , which allows you to use a lot of things (for example, the answer in this thread: What does "#define _GNU_SOURCE" mean? ).

When Perl is created without thread support, these flags are skipped and many bits from the header files remain commented out.
Perl doesn't seem to be affected. Even older versions of Apache were not, but Apache 2.2+ started using code that _GNU_SOURCE included, and building mod_perl not as simple as before.

I do not know who should do this. Maybe the main Perl-supporting ones themselves, maybe Apache helpers, maybe no one, and this is just a question about my case or compiler.

Conclusion: when creating non-streaming Perl _GNU_SOURCE not used, as a result, Perl .h files contain many #define comments and cannot create mod_perl for Apache 2.2+ sources. When creating Perl, you must add the additional -Accflags='-D_GNU_SOURCE' .

Other answers are welcome. Maybe I'm wrong or just see the tip of the iceberg.