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] |
Ian Grant <I.A.N.Grant@damtp.cam.ac.uk> writes: > 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. This is mainly why I wanted to use the dynlink package, because it seems to be able to figure out where the .so is, so it's partly laziness (ok, mostly laziness ;). The fact that it wouldn't resolve stat using the (dynamic-link ...) method was a bit of icing on the cake (though the sensible thing would be to blame this on the fact that I made the library by hand, it was 3 am, and the universe was obviously aligned against me). Most likely what I need is to get all the configuration stuff in place... at the very least, I can have a mess that I don't understand at all (and, it affords a few hours of staring blankly at info files and feeling really thick, which is always a special treat >:'). > 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 .... " Well, I'll have something, anyhow... though it's probably leaning more towards a nervous breakdown >;) -- Greg