6

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.

ArtMat
  • 2,110
  • 12
  • 24
  • Please state distro and architecture – Michael Slade May 06 '12 at 12:12
  • Try compiling with 5.14.2, the bug is likely already fixed because build bugs on Linux are easily spotted. 5.8.9 is **[not supported](http://p3rl.org/perlpolicy#MAINTENANCE-AND-SUPPORT)** anymore. I see you have reasonably modern versions of GCC, httpd and mod_perl, it makes no sense to cling to a Perl for which no one is likely to produce a work-around or bug-fix. – daxim May 06 '12 at 12:55
  • @daxim, I know that 5.8.9 is not supported anymore and 5.14 should be used, but I'll have to use not-threaded 5.8.9 and that's why this particular issue is affecting me. I just want to find what is going on there and why this happens. But for completness, I'll also try 5.14 and I'll compare both versions. – ArtMat May 06 '12 at 13:04
  • @daxim For the sake of completness, I also installed a fresh not-threaded ( `-Uusethreads` ) Perl v5.14.2 and it has exactly the same behaviour and the same errors related to `off64_t` which become `apr_off_t` errors when combined with Apache. `config.h` contains the same `#define HAS_OFF64_T` line commented (and a lot of others, compared to threaded version) – ArtMat May 06 '12 at 13:53

1 Answers1

3

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.

Community
  • 1
  • 1
ArtMat
  • 2,110
  • 12
  • 24