Re: Where do dynamic modules go?

[Marius Vollmer <mvo@zagadka.ping.de>]

Clark McGrew <mcgrew@ale.physics.sunysb.edu> writes:

> I need to use guile on several different architectures using
> dynamically linked modules.  The problem is where should I put the
> module .so files?  Is there any standard practice?

I'm not aware of any established practice for this.  I think what you
are proposing sounds fine, but I'm reluctant to push it to become the
standard Guile behaviour.

I'm currently rethinking this whole dynamic linking business.  The
current implementation tries to be smart about compiled code modules
and shared libraries, but I'm no longer sure it can really work.

Currently, Guile searches the %load-path for specially named shared
libraries and, upon finding them, turns them into modules.  I'm not
sure if this deals well with versioning of shared libraries,
inter-library dependencies and multiple modules in one shared library.
It never worked with muliple architectures, but I thought of the
dynamic linking of compiled code modules as such a short lived
experiment that I didn't want to introduce another path, like
%compiled-module-path.

I'm experimenting with a new approach in guile-gtk, the Guile bindings
to Gtk+ (and Gnome).  There, *every* module is required to be a *.scm
source file.  Such a Scheme file might decide to load and merge
compiled code from a shared library, with a call to
`merge-compiled-code'.  Like

    (define-module (gtk gdk)
      :use-module (gtk dynlink))

    (merge-compiled-code "sgtk_init_gtk_gdk_glue" "libguilegtk")

The shared library "libguilegtk" is searched in the usual places that
the runtime linker would try.  In addition, the current implementation
does some magic with installed libtool *.la files to get inter-library
dependencies and versioning right.  I expect to find this magic in dld
in the future, or at least in the Guile core.

[This also works when -lguilegtk has already been linked at compile
 time, regardless whether shared or static.]

> I think a good spot is "$(libdir)/guile/$(GUILE_VERSION)/$(ARCH)/..."

Why is $(ARCH) needed, shouldn't $(libdir) be already arch specific?
I know, emacs does it, too (with .../libexec), but why?