-
-
Notifications
You must be signed in to change notification settings - Fork 1.8k
Description
This is similar to gh-3882 but I think different because this is for dependencies found by pkgconfig. This comes from scientific-python/spin#176.
I have made a simple demo repo: https://github.com/oscarbenjamin/rpath_meson
I build gmp as an external dependency and install into a local directory and then try to make a Python extension module that links against it:
PREFIX=$(pwd)/.local
curl -O https://gmplib.org/download/gmp/gmp-6.3.0.tar.xz
tar -xf gmp-6.3.0.tar.xz
cd gmp-6.3.0
./configure --prefix=$PREFIX
make -j
make install
cd ..
PKG_CONFIG_PATH=$PREFIX/lib/pkgconfig meson setup build
meson compile -C build
meson install -C build --destdir ../build-install
export PYTHONPATH=$(pwd)/build-install/usr/local/lib/python3.12/site-packages
python -c 'import meson_test; print(meson_test.pow1000(2))'
This works fine on macos but fails on Linux. More precisely what fails is that at runtime it loads the system libgmp.so
(a different version) rather than the one in .local
so at least on this system it seems to work but is not correct.
We find gmp with:
gmp = dependency(
'gmp',
version: '>= 6.3.0',
)
The dependency is found using pkgconfig. I give an absolute path in PKG_CONFIG_PATH
which finds gmp.pc which also has absolute paths:
$ cat .local/lib/pkgconfig/gmp.pc
prefix=/home/oscar/current/active/rpath_meson/.local
exec_prefix=${prefix}
includedir=${prefix}/include
libdir=${exec_prefix}/lib
Name: GNU MP
Description: GNU Multiple Precision Arithmetic Library
URL: https://gmplib.org
Version: 6.3.0
Cflags: -I${includedir}
Libs: -L${libdir} -lgmp
However the binary built by meson compile
uses a relative rpath:
$ readelf -d build/src/meson_test/_meson_test.cpython-312-x86_64-linux-gnu.so
Dynamic section at offset 0x9d78 contains 26 entries:
Tag Type Name/Value
0x0000000000000001 (NEEDED) Shared library: [libgmp.so.10]
0x0000000000000001 (NEEDED) Shared library: [libc.so.6]
0x000000000000001d (RUNPATH) Library runpath: [$ORIGIN/../../../.local/lib]
...
That relative rpath is stripped out by meson install
so after install we can't find libgmp.so
any more (actually we get the system libgmp which is not what we want):
$ ldd build/src/meson_test/_meson_test.cpython-312-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007ffd0f79b000)
libgmp.so.10 => /home/oscar/current/active/rpath_meson/build/src/meson_test/../../../.local/lib/libgmp.so.10 (0x00007dc9af8f3000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007dc9af600000)
/lib64/ld-linux-x86-64.so.2 (0x00007dc9af980000)
$ ldd build-install/usr/local/lib/python3.12/site-packages/meson_test/_meson_test.cpython-312-x86_64-linux-gnu.so
linux-vdso.so.1 (0x00007ffd4d3ec000)
libgmp.so.10 => /lib/x86_64-linux-gnu/libgmp.so.10 (0x00007a1b6015b000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007a1b5fe00000)
/lib64/ld-linux-x86-64.so.2 (0x00007a1b60202000)
I don't see why a relative path is being used to an external dependency whose location is given as an absolute path. Certainly my intention at the end is that the binaries should reference my local build of libgmp.so
by absolute path which is what happens when running the same on macos rather than Linux.