Closed kevinsikes closed 1 year ago
@kevinsikes Thank you for this report. I'll work on getting this resolved. This was a hack I had to put in place for LD_LIBRARY_PATH
to be able to find the shared library when its next to the executable. I don't believe its possible to expand this variable so I'm not sure the proper way to fix this. Would having ${ORIGIN}
dropped be okay in your use case?
note for self: https://man7.org/linux/man-pages/man3/dladdr.3.html
Stripping off ${ORIGIN}
from the returned string seems sensible. Thanks for addressing!
@kevinsikes this issue should be fixed and will be in the next release
>>> import ics
>>> ics.get_library_path()
'/home/drebbe/dev/python_ics/.venv/lib/python3.10/site-packages/python_ics-913.8-py3.10-linux-x86_64.egg/ics/libicsneolegacy.so'
>>> ics.override_library_name('libicsneolegacy.so')
>>> ics.get_library_path()
'/home/drebbe/dev/python_ics/.venv/lib/python3.10/site-packages/python_ics-913.8-py3.10-linux-x86_64.egg/ics/libicsneolegacy.so'
>>> ics.override_library_name('${ORIGIN}/libicsneolegacy.so')
>>> ics.get_library_path()
'/home/drebbe/dev/python_ics/.venv/lib/python3.10/site-packages/python_ics-913.8-py3.10-linux-x86_64.egg/ics/libicsneolegacy.so'
In linux and windows we actually return the full absolute path now.
Calling
get_library_path()
with version 908.12 returns "libicsneolegacy.so" Callingget_library_path()
with version 911 or later returns "${ORIGIN}/libicsneolegacy.so"Expected behavior: No unresolved variable names would come back as part of the path string.
I am using an older libicsneo built from commit gf1d9be1 (libicsneo-v0.2.0-177-gf1d9be1_x86_64.deb is our internal package name), in case this makes a difference.