[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Thien-Thi Nguyen
Subject: Re: address@hidden: dynamic loading of native code modules]
Date: Wed, 24 Apr 2002 01:00:04 -0700

   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

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".

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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]