From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.user Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: Wed, 24 Apr 2002 09:33:33 -0500 Sender: guile-user-admin@gnu.org Message-ID: References: <87ads6nf1v.fsf@zagadka.ping.de> <87it6s7sjz.fsf@alice.rhinosaur.lan> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019659007 23789 127.0.0.1 (24 Apr 2002 14:36:47 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 14:36:47 +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 170Nt0-0006BT-00 for ; Wed, 24 Apr 2002 16:36:46 +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 170NsM-0004sG-00; Wed, 24 Apr 2002 10:36:06 -0400 Original-Received: from dsl-209-87-109-2.constant.com ([209.87.109.2] helo=defaultvalue.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 170Nq1-0004ia-00; Wed, 24 Apr 2002 10:33:41 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 30F74A126; Wed, 24 Apr 2002 09:33:40 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id C6FD311CE; Wed, 24 Apr 2002 09:33:33 -0500 (CDT) Original-To: ttn@glug.org In-Reply-To: (Thien-Thi Nguyen's message of "Wed, 24 Apr 2002 01:00:04 -0700") Original-Lines: 62 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.9 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:274 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:274 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. 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. > 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). It also means that we don't have to worry about name collisions. If you put all the libs in /usr/lib, then it's (filesystem wise) impossible to accidentally have shadowing of one lib by another with the same name and to have to deal with the mysterious errors that can cause. > 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. Any reason you have to be both condescending and insulting about this? Please feel free to post your obviously better solution, but don't forget to make sure it works across all the supported architectures and operating systems (I hear AIX is particularly nasty), both on the build side and on the runtime side, and that it doesn't cause serious packaging or dependency problems for any of the major distributions. While I get fairly aggravated with libtool (and libltdl) myself from time to time, I fully recognize the complexity of the problem they're trying to solve. Oh, and I'm not saying there isn't a better solution -- I'd be more than happy to explore the possibilities, but I consider your suggestion that "these people just chose this stupid solution because they like to be stupid" disingenuous at best, and it certainly doesn't inspire me, nor I suspect others, to want to work *with* you on the problem. -- Rob Browning rlb @defaultvalue.org, @linuxdevel.com, and @debian.org Previously @cs.utexas.edu GPG=1C58 8B2C FB5E 3F64 EA5C 64AE 78FE E5FE F0CB A0AD _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user