PyPANDA syscalls2 load-info fails to load shared libraries without LD_LIBRARY_PATH

[AndrewFasano]

From the pandare/panda:latest docker container, the following script aborts:

from pandare import Panda
panda = Panda(generic="i386")

panda.load_plugin("syscalls2", {"load-info": True})
panda.run()

with error

PANDA[syscalls2]:E:syscalls2_info.c(load_syscall_info)> syscalls2_dso_info_linux_x64.so: cannot open shared object file: No such file or directory
PANDA[core]:FAILED to load required plugin syscalls2 from /usr/local/lib/python3.8/dist-packages/pandare/data//x86_64-softmmu/panda/plugins//panda_syscalls2.so

It appears the pypanda installer has copied the various syscalls2_dso_info_linux_*.so libraries into /usr/local/lib/python3.8/dist-packages/pandare/data/[ARCH]-softmmu/panda/plugins/ but these aren't loaded successfully (even though regular plugins .sos like panda_syscalls2.so are in that directory and presumably loaded from there).

A workaround is to set the environment variable directly:

LD_LIBRARY_PATH "/usr/local/lib/python3.8/dist-packages/pandare/data/[ARCH]-softmmu/panda/plugins/"

[AndrewFasano]

Looks to be caused by syscalls2 directly using dlopen here while regular plugin loading does something more intelligent to construct the library path. We should probably make some sort of panda_find_library API function to do this the same way in both places.

[github-actions[bot]]

Stale issue message

[github-actions[bot]]

This issue has gone stale! If you believe it is still a problem, please comment on this issue or it will be closed in 30 days

[AndrewFasano]

Still a bug!

[AndrewFasano]

Turns out there's still a bug in here. Using the command line with our container, if you set load-info to True, it will be unable to find the dso shared object.