Re: updated $workbook/modules/modules-and-shared-libs.text

[Thien-Thi Nguyen]

   From: "Dale P. Smith" <address@hidden>
   Date: Tue, 21 May 2002 17:39:35 -0400

   [ lot's of stuff about the way modules/shared-libraries have changed ]

   I just noticed something recently:  I can no longer load a .so file from
   guile 1.6.x using load-extension.  I had to make a .la file (by copying
   one that was already in /usr/local/lib and editing it suitably) for it
   to work.

   Is it now necessary to use libtool (or whatever it's called) to make a
   .so that Guile can load?  Am I finally going to have to roll up my
   sleeves and dig into the auto* tools maze?

i could answer in a sneaky way, but let me lay my agenda bare: i want to
encourage users to get to know guile inside as well as out so that they
can maintain it over the long run.  this entails some learning; if we
record what we learn (instead of discussing aimlessly on mailing lists
w/ no conclusion) that's not so bad.  so if by-the-by you learn more
about the auto* tools (and share that), i think guile will benefit.

as for the particular hatchet job that is load-extension and all that it
entails, i partially sympathize w/ the intent of simplifying things.  to
be useful though, you cannot simplify too much, which is what happened.

so to answer your question, it depends on what kind of time scope you're
prepared to put into it: if you think in the long-term, you can help
design the "build-guile-compiled-module" program, starting at the user
interface (specifying command-line args/options), and someone (me or you
if you gain write privs and get to know libtool) will make it so.  this
design is then likely to be available w/ guile-1.6.x (or its successor
should 1.6.x be prematurely released).

if you think in the medium- or short-term, probably that means you want
to work around 1.6.x deficiencies, in which case i cannot help, because
to me all infrastructure-related work should be done in the context of
long-term thinking.

thi