[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: Tue, 14 May 2002 17:19:52 -0700

   From: Rob Browning <address@hidden>
   Date: Wed, 24 Apr 2002 10:28:14 -0500

   i.e. other apps are supposed to be able to
   link appropriately and then call scm_make_u8vector directly.

"directly linkable" is less important an attribute to consider than
"independently linkable".  to continue w/ this example, you still need
libguile around to make sense of `scm_make_u8vector' return value, that
is, libguile-srfi-srfi-4 is not independent of libguile.  understanding
this is crucial to understanding how much freedom you can gain by not
subscribing to system-wide conventions.

   It may well be that the subdirectory approach is suitable, and in fact
   its one I originally leaned toward, but I was shifted away after
   talking to Marius about direct linking and realizing that if we were
   going to properly version all our shared libs to accmodate  etc.

well, then i say you were swayed by fuzzy thinking -- "direct linking"
by 3rd party programs is a red herring for the plug-in system designer.
it's a nice feature to provide, but its implementation is best done
through the interface provided by libguile, aka `load-extension'.

btw, i think your ideas on extending `load-extension' argument list are
a good start.  concentrate on designing this abstraction interface in a
general way and you'll be fine -- do not confuse extension namespace and
sofile namespace.


reply via email to

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