How to force the path of a lib ?

[Neal Becker]

dieter wrote:

> 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.
> 

To follow up on that last point, look up --rpath and related.