This allows FFI modules to be specified in the same manner as you would when linking to them (-lGL --> GL, instead of /usr/lib/x86_64-linux-gnu/libGL.so as was required before this change, unless you manually placed /usr/lib/x86_64-linux-gnu in your LD_LIBRARY_PATH).
I don't know whether this will have unintended consequences for some use cases, since a lot of different systems end up calling this function. I tested the change for a while on Ubuntu 20.04 with no odd behavior occurring (but instead finally being able to load FFI modules without providing an absolute path or changing my LD_LIBRARY_PATH manually).
Some more insights on why this was necessary: We have a long list of different ways of resolving a module. Among those is looking through the directories in the LD_LIBRARY_PATH envvar, which however only contains those directories I manually added, not all that ldconfig would consider. In our list of directories, we were already passing an empty string once, which would do nothing unless an absolute path was given, since we only proceed to look up a library if the given path is a valid directory. Providing `dlopen` with just a library name, without any path information, however, allows it to look through all directories as configured in ldconfig. You can view, comment on, or merge this pull request online at:
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497
-- Commit Summary --
* unix: use dlopen's lookup mechanism when not specifying a path
-- File Changes --
M platforms/unix/vm/sqUnixExternalPrims.c (17)
-- Patch Links --
https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497.patch https://github.com/OpenSmalltalk/opensmalltalk-vm/pull/497.diff