[Vm-dev] Stupidifying FFI/library loading mechanism

Bert Freudenberg bert at freudenbergs.de
Thu May 26 22:11:05 UTC 2011


On 26.05.2011, at 23:45, Igor Stasenko wrote:

> On 26 May 2011 23:35, Bert Freudenberg <bert at freudenbergs.de> wrote:
>> 
>> On 26.05.2011, at 20:41, Denis Kudriashov wrote:
>> 
>> Hello
>> 
>> 2011/5/26 Igor Stasenko <siguctua at gmail.com>
>>> 
>>> loadInternalModule: moduleName
>>> loadExternalModule: moduleName path: pathToModuleLibrary
>>> 
>>> and by analogy, for FFI:
>>> 
>>> loadExternalLibrary: pathToExternalLibrary
>>> 
>> 
>> Can you explain what the difference between this kind of module loading. Why not enough just loadLibrary: pathToLibrary?
>> 
>> VM modules are not just arbitrary libraries. They provide primitive Smalltalk methods. They have special entry points like setInterpreter to be able to interface with the VM directly. Their location is known to the VM. Internal modules are already loaded. But they are still only "activated" when one of their primitive is called. They do the name-to-function-address mapping on their own rather than using the OS's name resolution mechanism.
>> Libraries loaded using FFI are just C libraries, nothing special about them. The provide C functions. Name lookup is done using OS functions. The VM can only guess about their location. Igor was proposing to take the guessing out of the VM and put it into the image.
> 
> What i finding fun that once you load B3D plugin, it already loads GL
> library, because it is linked with it.
> But it doesn't means that FFI can locate/use it :)

That is one advantage of using proper plugins, yes. Because linking the plugin uses the system linker. It will e.g. link it correctly to libGL.so.1 if that's what your system is using. Even though the name given in the Makefile is just "GL".

One problem people are experiencing with FFI under Linux in particular is that there is no "libGL.so" on most machines. That symlink only gets installed by the developer packages. "Regular" software links against specific library versions (e.g. libGL.so.1).

I wonder how other systems solve that problem. E.g. GNOME 3 introduces "GObject Introspection" which basically provides type annotations to generate FFI calls. But it still would need to figure out the proper library version. Maybe that's listed in the type library file? I don't know.

- Bert -




More information about the Vm-dev mailing list