elf: resolve paths in `ldd()` to purge relative path components ldd may return paths with relative components such as "..", e.g.: { 'linux-vdso.so.1': '', 'libc.so.6': '/snap/core/current/lib/x86_64-linux-gnu/libc.so.6', 'libnvidia-container.so.1': '/root/prime/usr/bin/../lib/x86_64-linux-gnu/libnvidia-container.so.1', 'libcap.so.2': '/snap/core/current/lib/x86_64-linux-gnu/libcap.so.2', 'libdl.so.2': '/snap/core/current/lib/x86_64-linux-gnu/libdl.so.2', 'libseccomp.so.2': '/snap/core/current/lib/x86_64-linux-gnu/libseccomp.so.2' } (1) Resolve the paths before using them to ensure we have a consistent values that do not look odd in potential warnings/errors (e.g. corrupted ELF). This also appears to expose an issue with the FakeElf fixture which was not creating a fake "barsnap.so.2" in the core base path. This updates the fixture to create one in the same manner as it does for the root libraries. (2) In the same example above, we can see linux-vdso has an empty string. In Ubuntu 16.04, ldd will return a slightly different formatted string which results in an empty path for the "found" shared object path. I do not believe it has caused a problem before attempting to use abspath on it. Check for the empty-string case and ignore it. We don't need to check linux-vdso, and calling abspath on it will resolve to the current working directory. Signed-off-by: Chris Patterson <chris.patterson@canonical.com>