[Vm-dev] plugin location

[Andreas Raab]

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

But it wouldn't find it in any of the "additional" locations that you 
were looking at, right? It's probably okay (most Unix users know that 
they have to set LD_LIBRARY_PATH) but I'm still a little concerned that 
this may break apps if people switch from one VM to the next. Perhaps 
leave it as an option for the FFI and drop it for good on the 4.0 
switch? (changes in major versions are just easier to explain than the 
change from 3.10-6 to 3.10-7 ;-)

It's your choice of course.

Cheers,
   - Andreas

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