I have noticed that with the latest release of 1.1.0, the lddwrap.list_dependencies fails when using it on a statically linked library:
my_static_lib.so:
statically linked
with the error message:
RuntimeError: Unexpected mem address. Expected to match ^\s*(([^)]))\s$, but got: 'linked'
This makes sense because normally, for a shared library, this is what you would get:
my_share_lib.so:
linux-lib.so.1 (0x00007fff4a9fe000)
linux-lib2.so => path
so statically linked is being parsed in the way that statically is considered to be the file and the linked is considered to be a memory address which of course fails the regex match.
Do you think that it would make more sense to avoid proceeding to the parsing step if ldd tells us that it's a statically linked library?
For the previous version, 1.0.1, it's happily reporting the following:
from pathlib import Path
import lddwrap
deps = lddwrap.list_dependencies(Path('my_static_lib.so'))
for dep in deps:
print(dep.path)
print(dep.found)
print(dep.soname)
statically
True
None
The statically is definitely not a correct file path, but raising an exception does not feel right either as ldd doesn't fail itself.
I have noticed that with the latest release of 1.1.0, the
lddwrap.list_dependenciesfails when using it on a statically linked library:with the error message:
This makes sense because normally, for a shared library, this is what you would get:
so
statically linkedis being parsed in the way thatstaticallyis considered to be the file and thelinkedis considered to be a memory address which of course fails the regex match.Do you think that it would make more sense to avoid proceeding to the parsing step if
lddtells us that it's a statically linked library?For the previous version, 1.0.1, it's happily reporting the following:
The statically is definitely not a correct file path, but raising an exception does not feel right either as
ldddoesn't fail itself.