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 byoff64_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.
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 #define
s 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.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With