Re: [PATCH] Thread Plug-in Support #2

[Marius Vollmer]

NIIBE Yutaka <address@hidden> writes:

> If it is OK, we just put the modules into
>       /usr/lib/guile/VERSION_OF_GUILE/MODULE.so
> 
> As Guile knows its version, there's no confusion to load modules
> compiled for other version's Guile.

Yes, this looks quite simple, and I would add, deceptively so.  I
can't say that I have extensive experience with Unix shared libraries,
but I would prefer a scheme where we are using shared libraries only
in `standard' ways.  That is, mainly put them in standard locations
and use the normal ways to link them.

I would like to view Guile extensions that are linked at run-time
foremost as normal shared libraries, not as plugins.  These extensions
shuld not only be useful to be linked in and add some Scheme bindings,
they should also be useful to be linked explicitely with other
extensions or applications.

For example, say we have a Guile extension `foo' that consists of some
Scheme code and a shared library libguile-foo.  The foo extensions
provides new features for Scheme code, but it also has things that are
useful from C.  Now, there is also the Guile extension `bar, with
libguile-bar.  Bar depends on foo, and libguile-bar uses features from
libguile-foo.  Libguile-bar is linked to libguile-foo at compile-time.

That is, libguile-foo is loaded explicitely by Guile when the user
requests the foo extension, implicitely as a dependency of
libguile-bar, and is also used at compile-time by the linker.  I'm not
sure whether this would work out nicely enough when libguile-foo is
installed in a non-standard place.


Maybe it can be made to work, and people are free to do it, but I
wouldn't want to recommend it as the standard way of installing Guile
extensions.