[Vm-dev] plugin location
piumarta at speakeasy.net
Thu Aug 27 03:45:39 UTC 2009
On Aug 26, 2009, at 8:02 PM, Andreas Raab wrote:
> Would this affect the FFI and its attempts to load platform libraries?
It would continue to find anything that dlopen() would find; i.e.,
anything with the platform's expected prefix and suffix in the
standard shared library locations including whatever influence
environment variables might have on the search.
In other words, I am suggesting:
1. The SQUEAK_PLUGINS or -plugins location (which could be multiple
paths separated by ':'s) with 'lib' prefix and '.so' suffix. This
finds the VM plugins on all platforms regardless of local library
naming conventions and permits non-installed libraries to override
2. The default places searched by dlopen() with the platform's
default library prefix and suffix added, unless there is a / in the
name in which case I'd pass it verbatim. This finds the FFI
libraries (which AFAICT don't tend to have prefix/suffix in their
module name in FFI declarations).
Anyone wanting to find platform libraries in non-standard places
(e.g., X11 on many non-Linux platforms) would have to provide a full
path to the library or set LD_LIBRARY_PATH (or whatever) as required.
John's report makes me think the above is almost reasonable. :)
> - Andreas
> Ian Piumarta wrote:
>> Does anyone use the plugin mechanism to load libraries that are
>> not plugins on Unix? Or to override just one or two of the
>> installed ones from a user directory?
>> I'm thinking of simplifying the search strategy (which is indeed
>> broken w.r.t. overriding installed plugins as Subbu points out)
>> along with all the junk related to probing for a zillion prefixes
>> and suffixes. Unlike libtool, CMake manages to build loadable
>> modules with predictable 'lib*.so' names regardless of the
>> platform. That, combined with a launch script that can add a -
>> plugins option to the VM args, suggests it ought to be possible to
>> find the plugin precisely on the first attempt, without having to
>> search at all.
>> The advantage is vastly simpler logic that is completely predictable.
>> The disadvantage is that it will not be possible to subvert the
>> plugin mechanism to load system libraries, and it will not be
>> possible to override the installed plugins with a single plugin
>> built in a different directory. Would either of these be a
>> noticeable loss?
More information about the Vm-dev