dieter wrote: > Vincent Vande Vyvre <vincent.vande.vy...@telenet.be> writes: >> I am working on a python3 binding of a C++ lib. This lib is installed >> in my system but the latest version of this lib introduce several >> incompatibilities. So I need to update my python binding. >> >> I'm working into a virtual environment (py370_venv) python-3.7.0 is >> installed into ./localpythons/lib/python3.7 >> >> So, the paths are: >> # python-3.7.0 >> ~/./localpythons/lib/python3.7/ >> # my binding python -> libexiv2 >> ~/./localpythons/lib/python3.7/site-packages/pyexiv2/*.py >> ~/./localpythons/lib/python3.7/site- packages/pyexiv2/libexiv2python.cpython-37m-x86_64-linux-gnu.so >> >> # and the latest version of libexiv2 >> ~/CPython/py370_venv/lib/libexiv2.so.0.27.0 >> >> All theses path are in the sys.path >> >> Now I test my binding: >>>>> import pyexiv2 >> Traceback (most recent call last): >> File "<stdin>", line 1, in <module> >> File >> "/home/vincent/CPython/py370_venv/lib/python3.7/site- packages/py3exiv2-0.1.0-py3.7-linux-x86_64.egg/pyexiv2/__init__.py", >> line 60, in <module> >> import libexiv2python >> ImportError: >> /home/vincent/CPython/py370_venv/lib/python3.7/site- packages/py3exiv2-0.1.0-py3.7-linux-x86_64.egg/libexiv2python.cpython-37m- x86_64-linux-gnu.so: >> undefined symbol: _ZN5Exiv27DataBufC1ERKNS_10DataBufRefE >>>>> >> >> Checking the libexiv2.so the symbol exists >> ~/CPython/py370_venv/lib$ objdump -T libexiv2.so.0.27.0 >> .... >> 000000000012c8d0 g DF .text 000000000000000f Base >> _ZN5Exiv27DataBufC1ERKNS_10DataBufRefE >> .... >> >> But it is not present into my old libexiv2 system, so I presume python >> use /usr/lib/x86_64-linux-gnu/libexiv2.so.14.0.0 (The old 0.25) instead >> of ~/CPython/py370_venv/lib/libexiv2.so.0.27.0 (The latest 0.27) >> >> How can I solve that ? > > To load external C/C++ shared objects, the dynamic lickage loader > (ldd) is used. "ldd" does not look at Pthon's "sys.path". > Unless configured differently, it looks at standard places > (such as "/usr/lib/x86_64-linux-gnu"). > > You have several options to tell "ldd" where to look for > shared objects: > > * use the envvar "LD_LIBRARY_PATH" > This is a "path variable" similar to the shell's "PATH", > telling the dynamic loader in which directories (before > the standard ones) to look for shared objects > > * use special linker options (when you link your Python > extension shared object) to tell where dependent shared > object can be found. >
To follow up on that last point, look up --rpath and related. -- https://mail.python.org/mailman/listinfo/python-list
