From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: rm@fabula.de Newsgroups: gmane.lisp.guile.devel Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: Wed, 24 Apr 2002 16:51:30 +0200 Sender: guile-devel-admin@gnu.org Message-ID: <20020424145130.GC17392@www> References: <87ads6nf1v.fsf@zagadka.ping.de> <87it6s7sjz.fsf@alice.rhinosaur.lan> <87662hkvya.fsf@raven.i.defaultvalue.org> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019660084 26170 127.0.0.1 (24 Apr 2002 14:54:44 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 14:54:44 +0000 (UTC) Cc: ttn@glug.org, 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 170OAN-0006nz-00 for ; Wed, 24 Apr 2002 16:54:44 +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 170O70-0005hO-00; Wed, 24 Apr 2002 10:51:14 -0400 Original-Received: from www.elogos.de ([212.18.192.92]) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 170O4Z-0005bh-00; Wed, 24 Apr 2002 10:48:43 -0400 Original-Received: by www.elogos.de (Postfix, from userid 5001) id C19CC1049A3; Wed, 24 Apr 2002 16:51:30 +0200 (CEST) Original-To: Rob Browning Content-Disposition: inline In-Reply-To: <87662hkvya.fsf@raven.i.defaultvalue.org> User-Agent: Mutt/1.3.24i 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:492 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:492 On Wed, Apr 24, 2002 at 09:33:33AM -0500, 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'd say "follow the masses". What do applications like Apache, Perl, Python etc. do? They all come with their 'private' locations for application specific libraries (let's call them plug-ins, since this seems to describe their function). Why is manipulation of an _applications_ LD_LIBRARY_PATH an un- acceptable behaviour (only applications exec'ed by guile would notice this, anyway) ? > Also, you do have to worry about distribution packaging systems -- > make sure that everyone's going to be ok, inter-package > dependency-wise with us placing libs in non-standard locations. Again, it doesn't seem to be a problem in other languages that support FFI. One _major_ benefit would be the possibility to have multiple versions of guile not interfere with each other. As an example: i currently have both /usr/lib/python1.5, /usr/lib/python2.0 and /usr/lib/python2.1 on my box. Trying to do the same with guile turned out to be rather complex. Ralf Mattes _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel