[OpenSmalltalk/opensmalltalk-vm] unix: use dlopen's lookup mechanism when not specifying a path (#497)
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
This might be helpful to consider usable paths and might get around the problem of mismatching libraries on the search path: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/pl...
As well as this: https://github.com/OpenSmalltalk/opensmalltalk-vm/blob/Cog/platforms/unix/pl...
@krono Hm interesting. I'm quite surprised how complex that code appears. What corner cases is it intended to catch? Is this code also invoked when linking to OpenSSL at compile time or only at runtime?
My understanding of dlopen() was that if you provide the minimal amount of information (i.e. just the library name, no paths, no .so versions), it would just go head and figure out "the right thing" for you based on the user's system configuration. But the way this looks I'd assume that my guess is quite off here :D
My understanding of dlopen() was that if you provide the minimal amount of information (i.e. just the library name, no paths, no .so versions), it would just go head and figure out "the right thing" for you based on the user's system configuration. But the way this looks I'd assume that my guess is quite off here :D
Unless you're unlucky and it finds a library of the name you gave it but it has the wrong architecture, for example, whereas it whould have been found given the right paths. :)
I was under the impression that dlopen would be smart enough to figure out what libraries are compatible with its caller process. Do we happen to have setups where odd behavior can be reproduced so we could try and give this code a spin in place of the more complex one that's currently in squeakssl (and also to make sure this code will keep working for FFI under such circumstances)?
Paging @eliotmiranda; he might eludicate the problems, he put all the `LD_` magic in the `.sh` because of some of these problems.
We should lookt at this one more time
@eliotmiranda approved this pull request.
Merged #497 into Cog.
vm-dev@lists.squeakfoundation.org
-
Eliot Miranda -
Tobias Pape
-
Tom Beckmann