带有自定义共享库的 Python C 扩展链接

Question

我正在一个非常古老的 Red Hat 系统上编写 Python C 扩展。系统有 zlib 1.2.3，它不能正确支持大文件。不幸的是，我不能只将系统 zlib 升级到较新的版本，因为某些软件包会插入内部 zlib 结构，并且会在较新的 zlib 版本上中断。

我想构建我的扩展，以便所有 zlib 调用（gzopen()、gzseek() 等）都解析为我安装在我的用户目录中的自定义 zlib，而不会影响 Python 可执行文件的其余部分和其他扩展。

我尝试通过在链接期间将libz.a 添加到 gcc 命令行来静态链接libz.a，但它不起作用（例如，仍然无法使用gzopen() 创建大文件）。我也尝试将-z origin -Wl,-rpath=/path/to/zlib -lz 传递给 gcc，但这也没有用。

由于较新版本的 zlib 仍然命名为 zlib 1.x，soname 是相同的，所以我认为符号版本不起作用。有没有办法做我想做的事？

我使用的是 32 位 Linux 系统。 Python版本是2.6，是定制的。

编辑：

我创建了一个最小的示例。我正在使用 Cython（版本 0.19.1）。

文件gztest.pyx：

from libc.stdio cimport printf, fprintf, stderr
from libc.string cimport strerror
from libc.errno cimport errno
from libc.stdint cimport int64_t

cdef extern from "zlib.h":
    ctypedef void *gzFile
    ctypedef int64_t z_off_t

    int gzclose(gzFile fp)
    gzFile gzopen(char *path, char *mode)
    int gzread(gzFile fp, void *buf, unsigned int n)
    char *gzerror(gzFile fp, int *errnum)

cdef void print_error(void *gzfp):
    cdef int errnum = 0
    cdef const char *s = gzerror(gzfp, &errnum)
    fprintf(stderr, "error (%d): %s (%d: %s)\n", errno, strerror(errno), errnum, s)

cdef class GzFile:
    cdef gzFile fp
    cdef char *path
    def __init__(self, path, mode='rb'):
        self.path = path
        self.fp = gzopen(path, mode)
        if self.fp == NULL:
            raise IOError('%s: %s' % (path, strerror(errno)))

    cdef int read(self, void *buf, unsigned int n):
        cdef int r = gzread(self.fp, buf, n)
        if r <= 0:
            print_error(self.fp)
        return r

    cdef int close(self):
        cdef int r = gzclose(self.fp)
        return 0

def read_test():
    cdef GzFile ifp = GzFile('foo.gz')
    cdef char buf[8192]
    cdef int i, j
    cdef int n
    errno = 0
    for 0 <= i < 0x200:
        for 0 <= j < 0x210:
            n = ifp.read(buf, sizeof(buf))
            if n <= 0:
                break

        if n <= 0:
            break

        printf('%lld\n', <long long>ifp.tell())

    printf('%lld\n', <long long>ifp.tell())
    ifp.close()

文件setup.py：

import sys
import os

from distutils.core import setup
from distutils.extension import Extension
from Cython.Distutils import build_ext

if __name__ == '__main__':
    if 'CUSTOM_GZ' in os.environ:
        d = {
            'include_dirs': ['/home/alok/zlib_lfs/include'],
            'extra_objects': ['/home/alok/zlib_lfs/lib/libz.a'],
            'extra_compile_args': ['-D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g3 -ggdb']
        }
    else:
        d = {'libraries': ['z']}
    ext = Extension('gztest', sources=['gztest.pyx'], **d)
    setup(name='gztest', cmdclass={'build_ext': build_ext}, ext_modules=[ext])

我的自定义zlib 在/home/alok/zlib_lfs（zlib 版本 1.2.8）中：

$ ls ~/zlib_lfs/lib/
libz.a  libz.so  libz.so.1  libz.so.1.2.8  pkgconfig

使用这个libz.a编译模块：

$ CUSTOM_GZ=1 python setup.py build_ext --inplace
running build_ext
cythoning gztest.pyx to gztest.c
building 'gztest' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/home/alok/zlib_lfs/include -I/opt/include/python2.6 -c gztest.c -o build/temp.linux-x86_64-2.6/gztest.o -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -g3 -ggdb
gcc -shared build/temp.linux-x86_64-2.6/gztest.o /home/alok/zlib_lfs/lib/libz.a -L/opt/lib -lpython2.6 -o /home/alok/gztest.so

gcc 正在传递我想要的所有标志（添加到 libz.a 的完整路径、大文件标志等）。

要在没有自定义 zlib 的情况下构建扩展，我可以在没有定义 CUSTOM_GZ 的情况下进行编译：

$ python setup.py build_ext --inplace
running build_ext
cythoning gztest.pyx to gztest.c
building 'gztest' extension
gcc -fno-strict-aliasing -DNDEBUG -g -fwrapv -O3 -Wall -Wstrict-prototypes -fPIC -I/opt/include/python2.6 -c gztest.c -o build/temp.linux-x86_64-2.6/gztest.o
gcc -shared build/temp.linux-x86_64-2.6/gztest.o -L/opt/lib -lz -lpython2.6 -o /home/alok/gztest.so

我们可以检查gztest.so文件的大小：

$ stat --format='%s %n' original/gztest.so custom/gztest.so 
62398 original/gztest.so
627744 custom/gztest.so

因此，静态链接的文件比预期的要大得多。

我现在可以做：

>>> import gztest
>>> gztest.read_test()

它会尝试读取当前目录中的foo.gz。

当我使用非静态链接 gztest.so 执行此操作时，它会按预期工作，直到它尝试读取超过 2 GB 的数据。

当我使用静态链接的gztest.so 执行此操作时，它会转储核心：

$ python -c 'import gztest; gztest.read_test()'
error (2): No such file or directory (0: )
0
Segmentation fault (core dumped)

关于No such file or directory 的错误具有误导性——文件存在并且是gzopen() 实际上返回成功。 gzread() 失败了。

这是gdb 回溯：

(gdb) bt
#0  0xf730eae4 in free () from /lib/libc.so.6
#1  0xf70725e2 in ?? () from /lib/libz.so.1
#2  0xf6ce9c70 in __pyx_f_6gztest_6GzFile_close (__pyx_v_self=0xf6f75278) at gztest.c:1140
#3  0xf6cea289 in __pyx_pf_6gztest_2read_test (__pyx_self=<optimized out>) at gztest.c:1526
#4  __pyx_pw_6gztest_3read_test (__pyx_self=0x0, unused=0x0) at gztest.c:1379
#5  0xf769910d in call_function (oparg=<optimized out>, pp_stack=<optimized out>) at Python/ceval.c:3690
#6  PyEval_EvalFrameEx (f=0x8115c64, throwflag=0) at Python/ceval.c:2389
#7  0xf769a3b4 in PyEval_EvalCodeEx (co=0xf6faada0, globals=0xf6ff81c4, locals=0xf6ff81c4, args=0x0, argcount=0, kws=0x0, kwcount=0, defs=0x0, defcount=0, closure=0x0) at Python/ceval.c:2968
#8  0xf769a433 in PyEval_EvalCode (co=0xf6faada0, globals=0xf6ff81c4, locals=0xf6ff81c4) at Python/ceval.c:522
#9  0xf76bbe1a in run_mod (arena=<optimized out>, flags=<optimized out>, locals=<optimized out>, globals=<optimized out>, filename=<optimized out>, mod=<optimized out>) at Python/pythonrun.c:1335
#10 PyRun_StringFlags (str=0x80a24c0 "import gztest; gztest.read_test()\n", start=257, globals=0xf6ff81c4, locals=0xf6ff81c4, flags=0xffbf2888) at Python/pythonrun.c:1298
#11 0xf76bd003 in PyRun_SimpleStringFlags (command=0x80a24c0 "import gztest; gztest.read_test()\n", flags=0xffbf2888) at Python/pythonrun.c:957
#12 0xf76ca1b9 in Py_Main (argc=1, argv=0xffbf2954) at Modules/main.c:548
#13 0x080485b2 in main ()

其中一个问题似乎是回溯中的第二行引用了libz.so.1！如果我这样做ldd gztest.so，我会得到：

    libz.so.1 => /lib/libz.so.1 (0xf6f87000)

我不知道为什么会这样。

编辑 2：

我最终做了以下事情：

• 用z_前缀导出的所有符号编译了我的自定义zlib。 zlib 的 configure 脚本让这一切变得非常简单：只需运行 ./configure --zprefix ...。
• 在我的 Cython 代码中调用 gzopen64() 而不是 gzopen()。这是因为我想确保我使用了正确的“基础”符号。
• 明确使用z_off64_t。
• 将我的自定义zlib.a 静态链接到 Cython 生成的共享库中。我在与 gcc 链接时使用了'-Wl,--whole-archive /home/alok/zlib_lfs_z/lib/libz.a -Wl,--no-whole-archive' 来实现这一点。可能还有其他方法，或者可能不需要这样做，但这似乎是确保使用正确库的最简单方法。

通过上述更改，大文件可以正常工作，而其他 Python 扩展模块/进程可以正常工作。

Answer 1

看起来这与another question 中的问题类似，但我得到了相反的行为。

我下载了zlib-1.2.8 的压缩包，运行./configure，然后更改了以下Makefile 变量...

CFLAGS=-O3  -fPIC -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64

SFLAGS=-O3  -fPIC -D_LARGEFILE64_SOURCE=1 -D_FILE_OFFSET_BITS=64

...主要是将-fPIC 添加到libz.a，以便我可以在共享库中链接到它。

然后我在gzlib.c 函数gzopen()、gzopen64() 和gz_open() 中添加了一些printf() 语句，这样我就可以很容易地判断它们是否被调用了。

在构建libz.a 和libz.so 之后，我创建了一个非常简单的foo.c...

#include "zlib-1.2.8/zlib.h"

void main()
{
    gzFile foo = gzopen("foo.gz", "rb");
}

...并编译了foo 独立二进制文件和foo.so 共享库...

gcc -fPIC -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 -o foo.o -c foo.c
gcc -o foo foo.o zlib-1.2.8/libz.a
gcc -shared -o foo.so foo.o zlib-1.2.8/libz.a

运行 foo 按预期工作，并打印...

gzopen64
gz_open

...但是在 Python 中使用 foo.so...

import ctypes

foo = ctypes.CDLL('./foo.so')
foo.main()

...没有打印任何东西，所以我猜是使用 Python 的 libz.so...

$ ldd `which python`
        ...
        libz.so.1 => /lib/x86_64-linux-gnu/libz.so.1 (0x00007f5af2c68000)
        ...

...即使foo.so 不使用它...

$ ldd foo.so
        linux-vdso.so.1 =>  (0x00007fff93600000)
        libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fc8bfa98000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fc8c0078000)

我可以让它工作的唯一方法是直接打开自定义libz.so...

import ctypes

libz = ctypes.CDLL('zlib-1.2.8/libz.so.1.2.8')
libz.gzopen64('foo.gz', 'rb')

...打印出来...

gzopen64
gz_open

请注意，从gzopen 到gzopen64 的转换是由预处理器完成的，所以我必须直接调用gzopen64()。

所以这是修复它的一种方法，但更好的方法可能是重新编译您的自定义 Python 2.6 以链接到静态 zlib-1.2.8/libz.a，或完全禁用 zlibmodule.c，然后您将拥有更大的灵活性链接选项。

---

更新

关于_LARGEFILE_SOURCE 与_LARGEFILE64_SOURCE：我只是因为zlib.h 中的评论才指出这一点...

/* provide 64-bit offset functions if _LARGEFILE64_SOURCE defined, and/or
 * change the regular functions to 64 bits if _FILE_OFFSET_BITS is 64 (if
 * both are true, the application gets the *64 functions, and the regular
 * functions are changed to 64 bits) -- in case these are set on systems
 * without large file support, _LFS64_LARGEFILE must also be true
 */

...这意味着如果您不定义_LARGEFILE64_SOURCE，gzopen64() 函数将不会被公开。我不确定_LFS64_LARGEFILE 是否适用于您的系统。

Answer 2

我建议使用ctypes。将您的 C 库编写为普通共享库，然后使用 ctypes 访问它。您需要编写更多 Python 代码来将数据从 Python 数据结构传输到 C 数据结构。最大的优势是您可以将所有内容与系统的其余部分隔离开来。您可以明确指定要加载的*.so 文件。不需要 Python C API。我对ctypes 有很好的体验。这对您来说应该不会太难，因为您似乎精通 C。