You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
build v1.10.0, --enable-rpath, fails to rpath python lib #222
...
checking for python... /usr/local/pyenv/versions/3.8-dev/bin/python3
checking for the distutils Python package... yes
checking for Python include path... -I/usr/local/pyenv/versions/3.8-dev/include/python3.8
checking for Python library path... -L/usr/local/pyenv/versions/3.8-dev/lib -L/usr/local/pyenv/versions/3.8-dev/lib/python3.8 -L. -lpython3.8
checking for Python site-packages path... /usr/local/pyenv/versions/3.8-dev/lib/python3.8/site-packages
checking consistency of all components of python development environment... yes
...
builds/installs with NO error
make
make install
but resulting bin is missing lib link,
ldd /usr/local/unbound/sbin/unbound | grep python
libpython3.8.so.1.0 => not found
OTOH, forcing the correct rpath'ing, building with
The rpath or finding dynamic libraries at runtime is a piece of system administration, not really our software. And I think in this case the solution may be in adding the library path for python 3.8 to the search path at runtime for dynamic libraries. For a Linux system over here that is man ld.so.conf or add a line with /usr/local/pyenv/versions/3.8-dev/lib to /etc/ld.so.conf or add a file with one line with /usr/local/pyenv/versions/3.8-dev/lib into the directory with ld.so.conf files and call it (for example) /etc/ld.so.conf.d/python3.conf . And then run ldconfig .
Or perhaps there is other information elsewhere about adding dynamic library paths to the dynamic library search path list. The rpath option is exactly for this use case though, eg. a user wants to have some libraries in locations not listed by the system and the rpath option lists the directory of the library into the binary so it can be found. So perhaps use rpath because that solves this problem precisely.
Since I got the impression that the problem is already solved, perhaps this is not that bug, or really some other issue like lack of documentation or so?
the problem is already solved, perhaps this is not that bug, or really some other issue like lack of documentation or so
I think the simplest question is, if "--enable-rpath" config option
...
--disable-rpath disable hardcoded rpath (default=enabled)
...
(this^^ is confusing a bit ... is rpath'ing ENABLED or DISABLED by default? or it it the CONFIG OPTION ...)
, doesn't actually properly hardcode lib paths, which is its purpose, then what's it for here? if it's failing to properly rpath all/any, or just some, of the linked libs, then that's a bug imo.
mod'ing LD_LIBRARY_PATH, a user-env changeable ENV var, is the wrong solution here for packaging.
We have that option for packagers that want to disable rpath. But the description looks clear to me. The bug is that when you enable rpath, it does not add the python directory to the rpath directory list.
Thanks for the report! Fixed it by adding the python lib directory to the rpath directory list (unless the lib dir is "/usr/lib" or "/usr/lib64").
Activity
wcawijngaards commentedon Apr 17, 2020
The rpath or finding dynamic libraries at runtime is a piece of system administration, not really our software. And I think in this case the solution may be in adding the library path for python 3.8 to the search path at runtime for dynamic libraries. For a Linux system over here that is
man ld.so.confor add a line with/usr/local/pyenv/versions/3.8-dev/libto/etc/ld.so.confor add a file with one line with/usr/local/pyenv/versions/3.8-dev/libinto the directory with ld.so.conf files and call it (for example)/etc/ld.so.conf.d/python3.conf. And then runldconfig.Or perhaps there is other information elsewhere about adding dynamic library paths to the dynamic library search path list. The rpath option is exactly for this use case though, eg. a user wants to have some libraries in locations not listed by the system and the rpath option lists the directory of the library into the binary so it can be found. So perhaps use rpath because that solves this problem precisely.
Since I got the impression that the problem is already solved, perhaps this is not that bug, or really some other issue like lack of documentation or so?
pgnd commentedon Apr 17, 2020
@wcawijngaards
hi
I think the simplest question is, if "--enable-rpath" config option
...
--disable-rpath disable hardcoded rpath (default=enabled)
...
(this^^ is confusing a bit ... is rpath'ing ENABLED or DISABLED by default? or it it the CONFIG OPTION ...)
, doesn't actually properly hardcode lib paths, which is its purpose, then what's it for here? if it's failing to properly rpath all/any, or just some, of the linked libs, then that's a bug imo.
mod'ing LD_LIBRARY_PATH, a user-env changeable ENV var, is the wrong solution here for packaging.
wcawijngaards commentedon Apr 20, 2020
We have that option for packagers that want to disable rpath. But the description looks clear to me. The bug is that when you enable rpath, it does not add the python directory to the rpath directory list.
Thanks for the report! Fixed it by adding the python lib directory to the rpath directory list (unless the lib dir is "/usr/lib" or "/usr/lib64").
Fix that it is --enable-rpath, for #222.
[-]build v1.10.0, --with-rpath, fails to rpath python lib[/-][+]build v1.10.0, --enable-rpath, fails to rpath python lib[/+]Merge remote-tracking branch 'nlnet/master'