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] |
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