Re: [Pharo-users] uFFI: Debugging "External module not found" Error
On Dec 3, 2019, at 11:34 AM, Sean P. DeNigris <sean@clipperadams.com> wrote:
Alistair Grant wrote
The same message is returned whether the module itself isn't found, or if one of its dependencies can't be found.
Secondary dependencies are awkward to track via command line.
Good to know. I wonder if we can't provide more detailed error messages here...
The following turned up in a search (I've no experience with it), but could be useful... https://linux.die.net/man/7/rtld-audit Or perhaps the system can examine the DYNAMIC section of an ELF to pre-load each dependency.
From the image, something in part equivalent to... https://github.com/finixbit/elf-parser/blob/master/elf_parser.cpp GT inspector on an ELF file could an interesting demo ;)
btw, I wasn't aware of how "Runtime Search Path: Security" affected the search path... https://amir.rachum.com/blog/2016/09/17/shared-libraries/
Alistair Grant wrote
On linux you can check dependencies with `ldd file.so`, I don't know what the Mac equivalent is.
Apparently, it's `otool -L whatever.dylib`, which returns: @rpath/libvlc.dylib (compatibility version 12.0.0, current version 12.0.0) @rpath/libvlccore.dylib (compatibility version 10.0.0, current version 10.0.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.50.4) /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
On Wed, 4 Dec 2019 at 03:58, Todd Blanchard via Pharo-users < pharo-users@lists.pharo.org> wrote:
This is the most annoying thing about UFFI - the library search seems to opaque and I don't understand how it works.
So far I am finding best practice is to find the library yourself and then provide the exact file path you want.
That way, you can actually prompt the user to find it if you don't and they get a decent experience.
cheers -ben P.S. an interesting side article... https://medium.com/forensicitguy/whitelisting-ld-preload-for-fun-and-no-prof...
participants (1)
-
Ben Coman