Re: Where should I install compiled modules please?

[Marius Vollmer]

Neil Jerram <address@hidden> writes:

> The key sentence, I think, is "The directories that the
> @file{%load-path} normally contains are supposed to contain only
> architecture independent files."  Why is this, or is the sentiment
> no longer accurate?

The sentence should not imply that %load-path should always only
contain directories with architecture-independent files.  It was meant
to just say that it normally contains only such directories and that
it would be a bad idea to put a shared library into any of these
directories.

That is, I didn't want people to look at the value of %load-path, pick
a directory from the list (for example, /usr/local/share/guile), and
put their libraries into that directory.  That would probably work for
them, but would not be the best solution because the directory would
usually be only intended for architecture-independent files.

I now recognize that the dynamic linking stuff that I did back then
was badly designed when it comes to the integration with thhe module
system.  I hace a better understanding of the situation now, I think,
but I'm hesitant to change the current system, because it seems to
work more or less and people have probably already `invested' into it.
I'd like to wait for Godot.

The way I prefer to do things right now is this: I have my
compiled-code module in a regular shared library that is installed in
a regular place in the system, like /usr/local/lib.  The library is
named something like "libguilefoo.la" but the name is not important
(as long as it is reasonably unique).  The library exports a function
name "foo_init_bar_module" or something.

Then I have a Scheme source file in the regular load path of Guile,
for example /usr/local/share/guile/foo/bar.scm, that implements the
(foo bar) module like this:

    (define-module (foo bar))

    (dynamic-call "foo_init_bar_module" (dynamic-link "libguilefoo"))

    (export foo-bla foo-blub ...)

[ When it becomes to tediuous to maintain the exports list, I use some
  more advanced module hackery to do that automatically. ]

In the two projects that I use this, I found that I need to use the
shared library that implements the guts of the (foo bar) module also
as a normal shared library for other compiled code.  That is, I need
to link it to other C code.  That other C code is also a shared
library that will get linked into a Guile process, and the only way I
feel confident that nothing strange happens is when I put the shared
libraries into the normal system places like /usr/local/lib.

For example, the shared library that implements guile-gtk contains
also the run-time support for widget bindings that are not contained
in the guile-gtk distribution (for example gnome-libs), and those
bindings need to link to libguilegtk-1.2.la, and when
libguilegtk-1.2.la is in some strange place and found via strange
names, I had it happen that it was linked _twice_ into the process
(because the dynamic linker did not recognize that it had already
loaded it).  This did not work, of course.

Hmm, I think I should rework the manual section about dynamic linking,
right?  I think I'll first want to take a survey on how people are
actually using it.