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

[Marius Vollmer]

Rob Browning <address@hidden> writes:

> Hmm.  In the end, ideally, I think you should be able to say:
> 
>   (use-modules (foo bar))
> 
> and get the (foo bar) module loaded, along with whatever other
> sub-modules it depends on, and whatever C shared libraries are needed.

Isn't that the case already?  The sub-modules are auto-loaded from the
various `use-modules' statements in the (foo bar) module itself, and
the shared libraries are linked with `dynamic-link' by the modules that
need them.
 
> *Ideally* you shouldn't have to specify a "version number" in the
> use-modules statement.  However, if we actually *want* versioning for
> guile level modules (which it's sounding like maybe we don't),

I think we don't need versioning badly, and if so, then first for
shared libraries, but versioning is certainly something to keep in
mind.

Luckily, Guile is flexible enough so that you can construct some
versioning yourself, without explicit support.  For example, you can
decide whether you want to use Gtk-1.2 or Gtk-1.3 (2.0 by now?) by
loading either the module (gtk-1.2 gtk) or (gtk-1.3 gtk).  When you
load just (gtk gtk) you get a default version.  When you load both,
you get an error.

> However, let's presume for the moment that we *don't* want to deal
> with guile level modules, then the only question is how do we deal
> with loading the right version of a C shared library that provides
> code that a given module (or modules) might need, especially if we
> want to support cases where (foo bar) needs libXXX implementation
> version 2 and (baz bax) needs libXXX implementation version 3.

Right.  We might not be able to support using two versions of one
library at the same time, however.  This would maybe work with
plugin-style libraries that don't implicitely export C-level symbols
to the rest of the program (linked with !RTLD_GLOBAL).  I think we
should avoid using plugin-style libraries if possible.  Normal
libraries can be used in more ways, I think (and are more conservative
;-).

> In that case, for now, it seems like the person writing a given
> module (which needs to load a C implementation part) will just have
> to know what version of the library suits their needs (which will
> usually just be whatever version is the current one), and then put
> that information into their module file:

Yes.

>   (define-module (foo bar))
> 
>   ;; Note the integer arg to dynamic-link...
>   (dynamic-call "foo_init_scm" (dynamic-link "libfoobar-main" 3))
>   (dynamic-call "foo_init_scm" (dynamic-link "libfoobar-extra" 5))
>   (dynamic-call "foo_init_scm" (dynamic-link "libfoobar-low" 9))

You would likely use different initialization functions here.
"foo_init_scm" should always refer to the exact same function.  You
might get away with reusing the name since ld.so does not seem to
check for duplicate symbols (which it should IMO), but it's certainly
bad style.

> I *think* that given libtool's conventions for versioning, from the
> shared library client side, you only need to specify the main version
> number of the library interface you need, so the single integer arg to
> dynamic-link might be all we need.

Yes.  I think on GNU/Linux, libltdl would just have to look for
"libfoobar-main.so.3" instead of "libfoobar-main.so".  What
it needs to do on other platforms, I don't know.