multithreading - 与启用线程的 Perl 相比，为什么非线程 Perl 不使用 off64_t 类型？

Question

我最初的任务是安装 mod_perl 2.0.6 + Apache 2.2.22。
该进程因与 off64_t 相关的许多错误而停止编译 mod_perl 时。于是，我开始深入挖掘。首先，我安装了 Perl 5.8.9 的两个新实例(因为我必须使用这个版本):一个线程版本和一个非线程版本(它们是相同的，只有 usethreads 不同)。尝试使用线程 Perl 重现相同的内容，但成功完成，但没有 off64_t错误。
结论很明显:线程化 Perl 提供了必要的 off64_t ，非线程的没有。
进一步搜索，我比较了config.h (来自 core/<arch>/CORE )两个 Perl'es，在 3671 行我可以看到这个(在非线程 Perl 中):

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

在启用线程的 Perl 中:

    #define HAS_OFF64_T            /**/

perl -V两个 Perl 实例报告 ccflags ='... -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 ...'作为使用的编译器标志。

据我了解，off64_t用于大文件，与线程无关。我找到了关于 off_t 的信息和 off64_t :

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

不久 :有 2 个相同的 Perl 版本，只有一个区别:usethreads配置参数。线程 Perl 启用 off64_t ，非线程的没有。

我的问题是:为什么会发生这种情况以及线程如何连接到此 off64_t应该用于大文件而不是线程的数据类型？

信息:Arch Linux OS 32 位(内核 2.6.33)、gcc 4.5.0、libc 2.11.1、标准 Perl 5.8.9

备注:off64_t在 Configure 中处理在第 15526 行，一个简单的 try.c生成并尝试编译。问题是为什么非线程 Perl 不能编译它而线程 Perl 可以。

Answer 1

我不确定回答我自己的问题是否是一种可以接受的行为，但是当我正在寻找解决方案而不仅仅是等待其他人做我的作业时，我认为这对其他人阅读本文会很有用。

很快，我的问题的答案是 -D_GNU_SOURCE gcc 编译器标志，似乎线程与此没有任何共同之处 off64_t类型。

看来，当 -Dusethreads用于 Configure , hints/linux.sh使用并执行以下代码:

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

然后用 _GNU_SOURCE 编译代码定义，它允许使用很多东西(就像在这些线程中回答: What does “#define _GNU_SOURCE” imply? )。

当 Perl 在没有线程支持的情况下构建时，这些标志会被跳过，头文件中的许多位仍然被注释。
Perl 本身似乎不受此影响。即使旧版本的 Apache 也没有，但 Apache 2.2+ 开始使用由 _GNU_SOURCE 启用的代码。和建筑mod_perl不像以前那么简单了。

我不知道谁应该注意这件事。也许核心 Perl 维护者自己，也许 Apache 维护者，也许没有人，这只是我的特殊情况或编译器问题。

结论:在构建非线程 Perl 时，_GNU_SOURCE未使用，因此 Perl .h文件有很多评论#define s 并针对 Apache 2.2+ 源构建 mod_perl 失败。附加 -Accflags='-D_GNU_SOURCE'应该在构建 Perl 时添加。

也欢迎其他答案。也许我错了，或者我只是看到了冰山的顶端。