From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Thien-Thi Nguyen Newsgroups: gmane.lisp.guile.devel Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: Wed, 24 Apr 2002 01:00:04 -0700 Sender: guile-devel-admin@gnu.org Message-ID: References: <87ads6nf1v.fsf@zagadka.ping.de> <87it6s7sjz.fsf@alice.rhinosaur.lan> Reply-To: ttn@glug.org NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1019635612 16701 127.0.0.1 (24 Apr 2002 08:06:52 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 08:06:52 +0000 (UTC) Cc: 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 170Hnf-0004LF-00 for ; Wed, 24 Apr 2002 10:06:51 +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 170HnQ-0000dD-00; Wed, 24 Apr 2002 04:06:36 -0400 Original-Received: from ca-crlsbd-u5-c4a-a-172.crlsca.adelphia.net ([24.48.214.172] helo=giblet) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170HlN-0000TL-00; Wed, 24 Apr 2002 04:04:29 -0400 Original-Received: from ttn by giblet with local (Exim 3.33 #1 (Debian)) id 170Hh6-0007Y8-00; Wed, 24 Apr 2002 01:00:04 -0700 Original-To: a.rottmann@gmx.at In-Reply-To: <87it6s7sjz.fsf@alice.rhinosaur.lan> (message from Andreas Rottmann on 15 Apr 2002 19:58:08 +0200) 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:488 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:488 From: Andreas Rottmann 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 _______________________________________________ Guile-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel