Re: address@hidden: dynamic loading of native code modules]

[Thien-Thi Nguyen]

   From: Andreas Rottmann <address@hidden>
   Date: 15 Apr 2002 19:58:08 +0200

   However, I have a suggestion: If the lib is only to be used by the
   .scm module (using load-extension), I see no point in putting it in
   ${libdir}. Instead it would be cleaner to be able to put it somewhere
   in ${libdir}/guile to avoid namespace cluttering in ${libdir} (which
   is, for example, (likely to be) indexed by the runtime linker on
   linux).

well i raised this point two (3?) years ago and the counter-point was
that all shared object libraries are the same and should be treated the
same.  of course, this is not entirely true; all the object libraries
we're interested in playing w/ via a scheme interface must depend on
libguile, minimally, and are loaded into a more restricted environment
than say "appfoo dynloads libbar.so".

placing all these libguile-dependent thingies in libdir directly means
we need to implement and enforce some kind of name flattening algorithm
should the thingies be hierarchical instead of using an already existing
file hierarchy organization (the filesystem hierarcy).  it also means we
are subject to the vagaries of the thingy-access program (libtool).

these are points i should have stressed more at that time, but i guess
when it comes to appreciating clutter, nothing beats experience...  so
now that dealing w/ libraries has proven to be a royal nightmare, i'm
hoping we can wake up and design the "guile object library" and its
access protocols and reverse this stupidity.

thi