6

我最初的任务是安装 mod_perl 2.0.6 + Apache 2.2.22。该过程因编译 mod_perl 时
出现许多错误而停止。off64_t于是，我开始深入挖掘。首先，我安装了两个新的 Perl 5.8.9 实例（因为我必须使用这个版本）：一个线程版本和一个非线程版本（它们是相同的，只是usethreads不同）。尝试使用线程化的 Perl 重现相同的内容并成功完成并且完全没有off64_t错误。
结论很明显：线程化的 Perl 提供了必要off64_t的，非线程化的则没有。
进一步搜索，我比较了两个 Perl 的config.h（来自core/<arch>/CORE），在第 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：

如果源是用_FILE_OFFSET_BITS = 64这种类型编译的（即off_t）透明地被替换为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

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

4

1 回答 1

3

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

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

似乎 when-Dusethreads用于Configure,hints/linux.sh并执行以下代码：

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

然后使用定义编译代码_GNU_SOURCE，这允许使用很多东西（就像在这些线程中回答的那样：“#define _GNU_SOURCE”意味着什么？）。

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

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

结论：在构建非线程 Perl 时，_GNU_SOURCE不使用，因此 Perl.h文件有很多注释#define，并且针对 Apache 2.2+ 源构建 mod_perl 失败。-Accflags='-D_GNU_SOURCE'构建 Perl 时应添加 一个附加项。

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

于 2012-05-06T19:39:04.027 回答