Re: Unable to load modules

[Andy Wingo]

Hey Greg,

>   # Probably will always be necessary to resolve libguile-gnome-gobject
>   # link.
[ld_library_path munging...]
>
> I think this is broken.  The code knows where the libraries are, and
> we should just  have
>
> (define (guile-gnome-dynamic-link f)
>         (dynamic-link (string-append
>                         *guile-gnome-libdir* "/"
>                         f)))

This is exactly what the (gnome gobject ...) modules do. The problem is
that the g-wrapped libs -- the ones that are dynamic-link'd by the
(gnome gw ...) modules -- actually *link* to libguile-gnome-gobject-0.so
(and to g-wrap runtime libs, and libguile, etc.). I don't think we should
hard-encode the path to the above lib, because it can be packaged
separately (and always will be, in the case of dbus for example), and
doing so ties the packages together too much, preventing a switch from a
hand-installed to a distribution-packaged version of guile-gnome-platform,
for instance.

I don't see the script as a problem, but there are cases when you won't be
running guile with it (for example, mod_guile). In these cases, you need a
programmatic interface to choose which version you want to run. In that
case, we can make a (gnome) module that exports one procedure, `version'.
You call version with a nonnegative integer to select an API version. Thus
in guile 1.6 you can have:

(use-modules (gnome)) (version 0)

While in guile 1.7 you can have the more compact (and less polluting)

((@ (gnome) version) 0)

Calling version will push $prefix/share/guile-gnome-$version onto the load
path. It could potentially link in
$prefix/lib/libguile-gnome-gobject-$version.so, exported as
*guile-gnome-gobject-lib*. If dynamic-link does a dlopen with RTDL_GLOBAL,
maybe we wouldn't have to munge the ld_library_path at all. I worry about
that though, that it might just be inviting bugs.

This is painful.

Wingo.