Re: [ANN] text buffers: really alpha release

[Greg Harvey <Greg.Harvey@thezone.net>]

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