在 Linux 上链接 python 的共享库时出现问题

Question

当我尝试在 linux VM 上设置我的代码时。该库已正确安装，我可以引用它并且运行可以顺利使用 C 代码。然而，当我试图将它编译成一个供 Python ctypes 使用的共享库时。编译没有像我在macOS上那样成功。编译后，我运行 python代码，直接报了Segmentation fault。有没有人遇到同样的问题并且知道如何解决这个问题？

以下是我的编译方式：

gcc -nostartfiles -o vrf.o -I/home/Data/libsodium/include -L/home/Data/libsodium/lib vrf.c
gcc -shared -fPIC -I/home/Data/libsodium/include -fPIC /home/Data/libsodium/lib/libsodium.a -L/home/Data/libsodium/lib -o vrf.so vrf.c

我试过从 .c 或 .o 文件编译它，但都失败了。 link 是 link 我在 /home/Data/libsodium 安装位置引用的库当我将它编译为可执行 .o 文件时，linux 给出了

的错误

/lib/gcc/x86_64-redhat-linux/4.8.5/../../../../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
collect2: error: ld returned 1 exit status

然后我添加了-nostartfiles，这在将它编译到共享库时引发了另一个警告

warning: Cannot create .eh_frame_hdr section, --eh-frame-hdr ignored.
/usr/bin/ld: error in vrf.o(.eh_frame); no .eh_frame_hdr table will be created

唯一的区别是，在 mac 上，共享库是用静态 .a 文件 link 编辑的，而在 linux 上，我尝试了相同的编译，但失败了。

Answer 1

愤怒activity不能代替理解。您似乎在随机 command-line 尝试不同的 command-line 标志 时四处乱窜 ，并且以这种方式绊倒正确标志的机会很小。

您想要的正确命令行是（几乎是您拥有的）：

gcc -shared -fPIC -I/home/Data/libsodium/include -o vrf.so vrf.c /home/Data/libsodium/lib/libsodium.a

请注意 libsodim.a 必须跟随 vrf.c，因为那是 how UNIX linkers work。

但是，上面的命令将不起作用，因为libsodium.a本身包含非PIC代码。

有两种方法可以解决这个问题：

您可以 re-build libsodium.a 使用 -fPIC 标记，或者
您可以使用 libsodium.so 并使 vrf.so 依赖于此。假设 libsodium.so 也安装在 /home/Data/libsodium/lib 中，正确的命令是：

gcc -shared -fPIC -I/home/Data/libsodium/include \ -L/home/Data/libsodium/lib -Wl,-rpath=/home/Data/libsodium/lib \ -o vrf.so vrf.c -lsodium

在 Linux 上链接 python 的共享库时出现问题

Problem linking shared library for python on Linux

c

linux

ctypes

shared-libraries