为什么非线程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:

如果使用_FILE_OFFSET_BITS = 64此类型编译源(即off_t)透明地替换为off64_t.

简而言之:有两个相同的Perl版本,只有一个区别:usethreadsconfigure参数.Threaded Perl启用off64_t,非线程Perl启用.

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

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

注释:在第15526行off64_t处理,生成Configure一个简单try.c的并尝试编译.问题是为什么非线程Perl无法在线程Perl可以编译它.

Answer 1

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

\n\n

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

\n\n

看起来，当-Dusethreads用于 ,时Configure，hints/linux.sh使用了以下代码：

\n\n

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

\n\n

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

\n\n

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

\n\n

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

\n\n

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

\n\n

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

\n