> 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-profit-98dfea740b9��

��