load_setuptools_entrypoints messing up with rpath
Closed this issue · 2 comments
Hello,
In short, I have an issue in my project on linux using pytest when a function from pluggy (load_setuptools_entrypoints) is called making the shared library dependency dynamic resolution ignoring the rpath. I'm going to add more details below, but don't hesitate to ask question if you need more information or if I am not clear.
We have the issue only on Linux (precisely Ubuntu 22), no issue on Mac (which has some differences about rpath) and no issue on windows (does not use rpath)
Everything we are building is done inside a venv , we use as little as possible system dependencies and everything that is build is installed inside this venv and we configure the rpath to point inside the lib directory of the venv.
For people who don't know in details what is the rpath here's a short explanation: it a variable you can set in your executable or shared library and it tells the loader where to find the shared library this executable (or library) needs.
We use it to use always use the library that we have installed in our venv.
We compile our openssl from source and we also build python from sources and it was configured to use our version of openssl, not the system one. We also have an internal library that I will call libA in C++ that depends on openssl. For this library we made bindings so we can use it in Python.
Now we have some Python code that use our compiled version of python and external dependencies are installed using pip inside our venv. And one of this dependency is pytest.
To recapitulate, we have in our venv: openssl, python, libA, libA bindings, and pytest and rpath.
When we run our code normally there is no issue, everything loads the right thing, except when using pytest, we noticed that it was ignoring the rpath and using the system openssl instead of our local one (and we upgrade our own version more often that the system one so it is an issue). I tracked down the issue and the rpath is ignored only after the function load_setuptools_entrypoints of pluggy is called by pytest.
# config/__init__.py line 1379
self.pluginmanager.load_setuptools_entrypoints("pytest11")We tried to disable the autoloading of pytest plugins with PYTEST_DISABLE_PLUGIN_AUTOLOAD but we need some plugins like pytest-gcov and the manual loading of pytest plugins also use load_setuptools_entrypoints so we probably would have the same issue. For now are workaround is to set the LD_LIBRARY_PATH env variable but this is practical at all.
My questions are:
- Why does this function mess up with the rpath?
- Is is possible to fix?
- Is there another workaround?
Feel free to tell me is this is more a pytest issue because of a misuse of pluggy.
pluggy itself is completely unaware of rpath, same goes for pytest - either one of the pytest plugins is affecting things, or the rpath change is simply triggered by an import
more details on pytest plugins and the environment is needed
pytest output that lists the active plugins and the paths may be helpfull,
additionally consider that the virtualenv creation might have an issue
my understanding is that the required python is the self-compiled one, how do you create the virtualenv, and how are the binaries to run your own tool and pytest created
my first random guess would be that the binary you create to run your tool are linked correctly, and the pytest script used to run pytest is simply accidentally using the wrong python
in which case things might simply look correct until ssl is imported (at which the order of operation gets critical as either your own openssl gets loaded first, thus shadowing the system one , or python loads its "correct" own ssl in turn shadowing yours
to verify this we need to investigate the python binaries of the venv as well as the generated scripts used for pytest
Thank you for your answer. I took a look closer at the venv creation and I can't go into details but the error is our side. I'm closing this issue.