get_library_path() returns unresolved variable ORIGIN as part of the string

[kevinsikes]

Calling get_library_path() with version 908.12 returns "libicsneolegacy.so" Calling get_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.

[drebbe-intrepid]

@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?

[drebbe-intrepid]

note for self: https://man7.org/linux/man-pages/man3/dladdr.3.html

[kevinsikes]

Stripping off ${ORIGIN} from the returned string seems sensible. Thanks for addressing!

[drebbe-intrepid]

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