與從python 3.5.2源構建的libpython3.5m.so相比，libpython3.so是什么？

Question

在我的應用程序中，我使用boost_python和python 3.5.2。 全部由Ubuntu 14。

當我在Ubuntu中使用--with-shared選項從源代碼構建Python 3.5.2時，我得到了libpython3.so （7.6kB）和libpython3.5m.so （12MB）。 我認為大的是真實的，小的可能是將呼叫轉發到真實接口的東西。

由於boost_python可能假設客戶端要鏈接到python（ https://svn.boost.org/trac/boost/ticket/2615 ），所以我將libpython3.so與我的應用程序鏈接了。 但是，當我運行它時，出現了無法解析的符號錯誤。

ldd -r myapp或ldd -r libboost_python.so都列出了所有未解析的python符號，這些符號可以在nm -D libpython3.5m.so找到。

# ldd -r lib/libboost_python3.so
    linux-vdso.so.1 => (0x00007ffe767fb000)
    libstdc+.so.6 => /usr/lib/x86_64-linux-gnu/libstdc+.so.6 (0x00007f130a7a3000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f130a58d000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f130a1c8000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f1309ec2000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f130acf4000)
undefined symbol: PyExc_ImportError (lib/libboost_python3.so)
undefined symbol: PyProperty_Type (lib/libboost_python3.so)
undefined symbol: PyExc_StopIteration (lib/libboost_python3.so)
undefined symbol: PyBool_Type (lib/libboost_python3.so)
undefined symbol: PyExc_ValueError (lib/libboost_python3.so)
undefined symbol: PyList_Type (lib/libboost_python3.so)
undefined symbol: _Py_NotImplementedStruct (lib/libboost_python3.so)
undefined symbol: PyExc_TypeError (lib/libboost_python3.so)
undefined symbol: PyDict_Type (lib/libboost_python3.so)
...

libpython3.so依賴於libpython3.5m.so但本身沒有這些符號。

我認為基於此，我應該將我的應用程序與libpython3.5m.so鏈接，而不是與libpython3.so 。 但是很奇怪的是，如果我使用LD_PRELOAD加載libpython3.so，那么這些符號可以在ldd -r libboost_python3.so中找到

# LD_LIBRARY_PATH=lib LD_PRELOAD=lib/libpython3.so ldd -r lib/libboost_python3.so
    linux-vdso.so.1 => (0x00007ffcb51f0000)
    lib/libpython3.so (0x00007f6f728e3000)
    libstdc+.so.6 => /usr/lib/x86_64-linux-gnu/libstdc+.so.6     (0x00007f6f725df000)
    libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f6f723c9000)
    libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f6f72004000)
    libpython3.5m.so.1.0 => lib/libpython3.5m.so.1.0 (0x00007f6f71ae1000)
    libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0     (0x00007f6f718c3000)
    libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f6f715bd000)
    /lib64/ld-linux-x86-64.so.2 (0x00007f6f72d32000)
    libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f6f713b9000)
    libutil.so.1 => /lib/x86_64-linux-gnu/libutil.so.1 (0x00007f6f711b6000)

為什么要擁有libpython3.so以及如何使用它？ 還是只直接使用libpython3.5m.so ？

Answer 1

libpython3.so庫在那里支持PEP 384-定義穩定的ABI 。

從歷史上看，Python不能保證次要版本之間（例如3.4和3.5之間）的C級ABI穩定性。 它們可能是源兼容的，但是某些結構可能會更改大小，或者結構成員會更改類型等。但是，ABI的某些部分已經成熟並且可以在更長的時間內保持穩定。

穩定的ABI PEP確定了Python C API的一個子集，如果開發人員致力於維護該子集的二進制兼容性，那么該子集不會對未來的Python開發施加不適當的限制。 如果程序或擴展將自身限制為僅使用此子集，則理論上可以在不重新編譯的情況下跨不同的Python版本使用它。

使用穩定的ABI編譯一些代碼后，仍然存在如何鏈接到運行時的問題。 對於Python 3.5.x，您需要使用-lpython3.5m進行鏈接。 對於Python 3.6.x，您需要-lpython3.6m 。 這是libpython3.so進入的地方。

libpython3.so庫僅具有一個用途：對於Python 3.5，它鏈接到libpython3.5m.so ，在3.6上它鏈接到libpython3.6m.so等。因此，如果擴展使用-lpython3鏈接，它將可以訪問系統上安裝的Python版本的運行時。

現在回到您的原始問題：除非您完全確定只使用穩定ABI中的功能（在您的情況下，這意味着確定libboost_python是否僅使用穩定ABI），那么您可能想要鏈接到版本化的libpython3.5m.so 。

如有疑問，最好鏈接到版本庫：調試動態鏈接錯誤比由於ABI更改而引起的段錯誤要容易得多，如果您升級到更新版本的Python。