This is the mail archive of the guile@cygnus.com mailing list for the guile project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [ANN] text buffers: really alpha release


On 24 Jan 1999, Greg Harvey wrote:

>                  ... An actually working from guile version should be
> available very soon (basically, it depends on how long it takes for me
> to figure out how to set it up to use guile-gtk's dynlink module for
> merging in the shared library with the scheme code, and how long it
> takes to get all those hairy configuration files ready, and it'll be
> all set). 

Marius has said he might start a discussion here about dynamically loading
guile modules from shared libraries when they depend upon other shared
libraries being loaded. Perhaps this is the time to start this. 

But first: I'm not quite sure why you need to use a dlopen helper library. 
Isn't your text buffer a stand-alone .so, not dependent upon any other
.so s? If so then Guile's module system should already be able to load it
without extra help. You just need the appropriate magic-named init
function to be present and the .so to be in the right place.

AFAIK Marius had to write his dlopen helper library so that he could
resolve inter-shared-library dependencies. That is, guile's module system
doesn't resolve the dependencies his gtk glue module has on the GTK+
shared libraries.

There is an alternative to this, which is to use a libtool from the
libtool CVS. This now supports building shared libraries that depend on
other shared libraries. It can do this because most library formats allow
for the inclusion of a search path for dependencies, and most link-loaders
can use these sanely. However I've yet to try it on anything other than
Linux, on which it works flawlessly. If you're worried about using a CVS
libtool then you could wait for libtool 1.3. It's due out soon, and it
should include this.

It seems to me this is the way to go, because it's a lot simpler: it's a
matter of adding two switches to the libtool invocation, rather than a
whole new shared library.

If you want a Makefile.am etc to look at then you could fetch guile-pg
from http://www.damtp.cam.ac.uk/user/ig206/guile-pg/ It's a set of glue
functions to link guile with a third-party shared library. It uses the new
libtool to do this. There are also some autoconf macros in acinclude.m4
that might be useful to you. 

Another related issue is where guile modules that are in shared libraries
should be installed. I described in an earlier message one way to resolve
the problem of putting architecture-specific binaries under PREFIX/share
(which is where guile looks for shared libraries that are to be loaded as
modules.) The coding standards prohibit this, for the good-enough reason
that the files cannot be shared across different platforms. I got around
this by making a symlink from the shared directory to the library
directory. The automake magic to do this is in the Makefile.am for
guile-pg.

Have fun. "You are in a twisty maze of m4 macros, all alike .... "

Ian