osdir.com


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

How to force the path of a lib ?


Vincent Vande Vyvre <vincent.vande.vyvre at 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.