[Vm-dev] plugin location

Ian Piumarta 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  
installed ones.

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. :)


> Cheers,
>   - 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?
>> Cheers,
>> Ian

More information about the Vm-dev mailing list