From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Rob Browning Newsgroups: gmane.lisp.guile.devel Subject: Re: [d.love@dl.ac.uk: dynamic loading of native code modules] Date: Wed, 24 Apr 2002 10:28:14 -0500 Sender: guile-devel-admin@gnu.org Message-ID: <871yd5ktf5.fsf@raven.i.defaultvalue.org> References: <87ads6nf1v.fsf@zagadka.ping.de> <87it6s7sjz.fsf@alice.rhinosaur.lan> <87662hkvya.fsf@raven.i.defaultvalue.org> <20020424145130.GC17392@www> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1019662231 31215 127.0.0.1 (24 Apr 2002 15:30:31 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Wed, 24 Apr 2002 15:30:31 +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 170Oj0-00087F-00 for ; Wed, 24 Apr 2002 17:30:31 +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 170Oir-0007o9-00; Wed, 24 Apr 2002 11:30:21 -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 170Ogp-0007i2-00; Wed, 24 Apr 2002 11:28:16 -0400 Original-Received: from raven.i.defaultvalue.org (raven.i.defaultvalue.org [192.168.1.7]) by defaultvalue.org (Postfix) with ESMTP id 5419B14E2; Wed, 24 Apr 2002 10:28:14 -0500 (CDT) Original-Received: by raven.i.defaultvalue.org (Postfix, from userid 1000) id 2E7A311CE; Wed, 24 Apr 2002 10:28:14 -0500 (CDT) Original-To: rm@fabula.de In-Reply-To: <20020424145130.GC17392@www> (rm@fabula.de's message of "Wed, 24 Apr 2002 16:51:30 +0200") Original-Lines: 74 User-Agent: Gnus/5.090006 (Oort Gnus v0.06) Emacs/21.2 (i386-debian-linux-gnu) 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:494 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.devel:494 rm@fabula.de writes: > 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) ? Aside from hearing people claim that "it's for user use only", I think one of the primary issues was with whether or not you put the additions at the beginning or the end -- i.e. do you allow the user to override your value for debugging purposes, etc? Another complaint if I recall correctly is that if you're inserting directories that aren't very *specific* you can cause other unwanted libs to be pulled in. i.e. inserting /usr/local/lib somewhere might be *bad*, but if we were only inserting /usr/lib/guile/1.8/ then that concern would be somewhat alleviated. One other concern would be what to do about add-ons -- i.e. you'd have to be careful to work out a strategy whereby things like guile-www, guile-pg, etc would have a place to put their libs that guile could find. Further, what if guile ships with a version of something like guile-pg built in, but now then user wants to use a new version of guile-pg. If we aren't careful, i.e. if we just append /usr/lib/guile/1.8 to the front of the LD_LIBRARY_PATH to be safe, we've now prevented the user from loading their newer version unless they install it in a way that clobbers the one inside the guile install dir, a no-no as far as most distributions are concerned. I can't recall off the top of my head if there are any stronger arguments against it. >> 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. Guile has planned to allow users to link directly against guile's internal libs, i.e. the user is supposed to compile an app and link against -llibguile-srfi-srfi-4 if they need that functionality[1]. I was under the (possibly mistaken) impression that python and perl didn't intend to support that, and if not, that affects how much flexibility you have. [1] i.e. other apps are supposed to be able to link appropriately and then call scm_make_u8vector directly. Bear in mind that allowing direct linking also means that you have to fully version all your shared libs in the traditional manner. This is complex, but does have a number of benefits, including being well understood on the OS side and allowing, if the distributions packaging guile handle things right, easy upgrades of guile independent of all the apps compiled against guile and it's various shared libs. That said, I totally agree that when we sit down to work on versioning scheme-level "use-modules modules", and on a better solution to the current situation wrt lt_dlopen and versioned shared libs, we should survey what the other languages are doing as part of the process. 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. -- 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-devel mailing list Guile-devel@gnu.org http://mail.gnu.org/mailman/listinfo/guile-devel