From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.lisp.guile.devel Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: Wed, 1 May 2002 00:00:30 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <0205010000300Q.10649@locke.free-expression.org> References: <87662hkvya.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 8bit X-Trace: main.gmane.org 1020229981 13750 127.0.0.1 (1 May 2002 05:13:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 1 May 2002 05:13:01 +0000 (UTC) Cc: a.rottmann@gmx.at, mvo@zagadka.ping.de, neil@ossau.uklinux.net, guile-devel@gnu.org, guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 172mQF-0003ZX-00 for ; Wed, 01 May 2002 07:13:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 172mPc-0004ax-00; Wed, 01 May 2002 01:12:20 -0400 Original-Received: from epimetheus.hosting4u.net ([209.15.2.70]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 172mEv-0003kb-00 for ; Wed, 01 May 2002 01:01:17 -0400 Original-Received: (qmail 17479 invoked from network); 1 May 2002 05:01:16 -0000 Original-Received: from leo.hosting4u.net (HELO free-expression.org) (209.15.2.51) by mail-gate.hosting4u.net with SMTP; 1 May 2002 05:01:16 -0000 Original-Received: from locke.free-expression.org ([156.56.116.32]) by free-expression.org ; Wed, 01 May 2002 00:01:11 -0500 Original-To: Rob Browning , ttn@glug.org X-Mailer: KMail [version 1.2] In-Reply-To: <87662hkvya.fsf@raven.i.defaultvalue.org> X-Rcpt-To: Errors-To: guile-devel-admin@gnu.org X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: Developers list for Guile, the GNU extensibility library List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.devel:570 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:570 On Wednesday 24 April 2002 09:33, Rob Browning wrote: > Thien-Thi Nguyen writes: > > > 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". > > And if we put them in some non-lib dir, do you propose that we > internally mangle the user's LD_LIBRARY_PATH in order to allow ldso to > find the libs? Many people consider this unacceptable application > behavior, so that's another point that somewhat weighs in favor of > using the standard directories. I don't think this is exactly accurate. The documentation I have for libltdl states (note the "in the order as follows"!): If libltdl cannot find the library and the file name FILENAME does not have a directory component it will additionally search in the following search paths for the module (in the order as follows): 1. user-defined search path: This search path can be set by the program using the functions `lt_dlsetsearchpath' and `lt_dladdsearchdir'. 2. libltdl's search path: This search path is the value of the environment variable LTDL_LIBRARY_PATH. 3. system library search path: The system dependent library search path (e.g. on Linux it is LD_LIBRARY_PATH). Each search path must be a colon-separated list of absolute directories, for example, `"/usr/lib/mypkg:/lib/foo"'. If the same module is loaded several times, the same handle is returned. If `lt_dlopen' fails for any reason, it returns `NULL'. which means you have 2 ways of searching that won't mess with normal shared library behaviour. Although it does look as though it won't play well when linking to library/application that uses libltdl for its own modules. You'd have to work around it by having a wrapper function switch the paths back and forth, and beware threads. Lynn _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel