Repository navigation
spin build should fix the rpath for shared libaries #176
Description
I'm migrating python-flint to meson-python and testing out spin as a frontend (flintlib/python-flint#129).
The setup that I use with python-flint is to build libraries with --prefix=$(pwd)/.local so that I have isolated builds of the C dependencies inside the python-flint development checkout.
When building wheels with meson-python I can set PKG_CONFIG_PATH to find the libraries and then meson-python fixes the rpath:
https://github.com/mesonbuild/meson-python/blob/c9d1c2dafb54692ad56dcda1bc67fd52b83b29c0/mesonpy/__init__.py#L431-L440
This means that I can do e.g.
$ PKG_CONFIG_PATH=$(pwd)/.local/lib/pkgconfig spin install
$ pip install --no-build-isolation --editable .
...
Successfully installed python-flint-0.6.0
$ python -m flint.test -qt
Running tests...
flint.test: all 49 tests passed!
----------------------------------------
OK: Your installation of python-flint seems to be working just fine!
----------------------------------------However spin build does not fix the rpath and so spin test does not work unless I set LD_LIBRARY_PATH:
$ PKG_CONFIG_PATH=$(pwd)/.local/lib/pkgconfig spin build --clean
...
[90/90] Linking target src/flint/functions/showgood.cpython-312-x86_64-linux-gnu.so
$ meson install --only-changed -C build --destdir ../build-install
$ spin test
Invoking `build` prior to running tests:
$ meson compile -C build
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /home/oscar/current/active/python-flint/build
ninja: Entering directory `/home/oscar/current/active/python-flint/build'
ninja: no work to do.
$ meson install --only-changed -C build --destdir ../build-install
$ export PYTHONPATH="/home/oscar/current/active/python-flint/build-install/usr/lib/python3.12/site-packages"
$ /home/oscar/.pyenv/versions/3.12.0/envs/python-flint-3.12/bin/python3.12 -P -c 'import flint'
Traceback (most recent call last):
File "<string>", line 1, in <module>
File "/home/oscar/current/active/python-flint/build-install/usr/lib/python3.12/site-packages/flint/__init__.py", line 1, in <module>
from .pyflint import *
File "pyflint.pyx", line 1, in init flint.pyflint
File "flint_base.pyx", line 1, in init flint.flint_base.flint_base
ImportError: libflint.so.19: cannot open shared object file: No such file or directory
As a sanity check, we tried to import flint.
Stopping. Please investigate the build error.
$ LD_LIBRARY_PATH=$(pwd)/.local/lib spin test
Invoking `build` prior to running tests:
$ meson compile -C build
INFO: autodetecting backend as ninja
INFO: calculating backend command to run: /usr/bin/ninja -C /home/oscar/current/active/python-flint/build
ninja: Entering directory `/home/oscar/current/active/python-flint/build'
ninja: no work to do.
$ meson install --only-changed -C build --destdir ../build-install
$ export PYTHONPATH="/home/oscar/current/active/python-flint/build-install/usr/lib/python3.12/site-packages"
$ /home/oscar/.pyenv/versions/3.12.0/envs/python-flint-3.12/bin/python3.12 -P -c 'import flint'
$ export PYTHONPATH="/home/oscar/current/active/python-flint/build-install/usr/lib/python3.12/site-packages"
$ cd /home/oscar/current/active/python-flint/build-install/usr/lib/python3.12/site-packages
$ /home/oscar/.pyenv/versions/3.12.0/envs/python-flint-3.12/bin/python3.12 -m pytest --rootdir=/home/oscar/current/active/python-flint/build-install/usr/lib/python3.12/site-packages flint
======================================== test session starts ========================================
platform linux -- Python 3.12.0, pytest-7.4.3, pluggy-1.3.0
rootdir: /home/oscar/current/active/python-flint/build-install/usr/lib/python3.12/site-packages
plugins: doctestplus-1.2.1, cov-4.1.0, hypothesis-6.88.4, xdist-3.4.0
collected 49 items
flint/test/test_stuff.py ................................................. [100%]
======================================== 49 passed in 3.86s =========================================I think that spin build should set the rpath somehow but I'm not sure where is the place that this should be fixed. I assume that it would be out of place for spin to manipulate the rpath entries directly like meson-python does.
Should meson set the rpath?
Should spin ask meson or meson-python to do it somehow?
Activity
rgommers commentedon Apr 4, 2024
Since editable installs already work for you, gh-155 to make editable installs work with
spinshould be helpful here.For the default
spin buildbehavior, I'm actually not 100% sure what is happening.This is probably not the relevant code, because it's about internal shared libraries, while the ones you have are external (not built as part of the
meson setup/meson compileinvocation as a subproject) ones, right?Normally Meson will take care of rpath rewriting during install. It's possible that that doesn't work for in-tree shared libraries because they're not considered external. Does it work without
LD_LIBRARY_PATHif you place them elsewhere, like$(pwd)/../.local/lib?The entries should have absolute paths for shared library dependencies that are not on the default loader search path. For example:
RPATH entry:
oscarbenjamin commentedon Apr 4, 2024
Yes, that's correct.
This is what I get from
ldd:This is what
readelfshows:I'm not sure why I have an extra usr like
build-install/usr/.... When building withspin buildI get:I don't think I've set that anywhere though...
rgommers commentedon Apr 4, 2024
Yep, this being a relative rather than an absolute path should be the problem.
That's the output of
meson, so "user defined" here is something set byspin.oscarbenjamin commentedon Apr 4, 2024
No, it still doesn't work in that case. I just get an extra
..:oscarbenjamin commentedon Apr 4, 2024
To be clear I used an absolute path to a directory outside of the working directory
but it somehow got turned into a relative path.
oscarbenjamin commentedon Apr 4, 2024
So cutting out spin then the problem is just:
We wanted an absolute path to be in the binary but we've been left with a relative one.
Should that be considered a bug in meson?
oscarbenjamin commentedon Apr 4, 2024
It all works fine on macos so I'm only seeing this problem on Linux.
stefanv commentedon May 1, 2024
@oscarbenjamin If I understand this issue correctly, this is a Meson problem. If you agree, we can close this, otherwise I can investigate further.
oscarbenjamin commentedon May 1, 2024
Yeah, this is just a meson issue I think.
oscarbenjamin commentedon May 8, 2024
The solution to this (mesonbuild/meson#13046 (comment)) is to set
LDFLAGSwhen callingspin buildi.e.:Possibly it would be useful for spin to add a more discoverable CLI option for that like
In flintlib/python-flint#135 I added a custom option
spin build --local-flint=.local/lib/pkgconfigwhich translates toThe
local_flintproject option sets the linker flags to install the rpaths.oscarbenjamin commentedon May 8, 2024
From the discussion in mesonbuild/meson#13046 I think that this is sort of a
spin-specific situation because of the fact that we are "installing" things into a local directory.rgommers commentedon May 8, 2024
I think it's specific to "build against a shared library that's not on the default loader search path", and is unrelated to the install location. I.e., whether you use
spinor use for examplepip install .should have the same failure mode (editable installs do not though, but regular installs will).