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.user Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix Date: Thu, 19 Sep 2002 17:27:59 +0200 Sender: guile-user-admin@gnu.org Message-ID: <20020919152759.GD7480@www> References: <20020918203311.3C5FA3F28@fnord.ir.bbn.com> <87k7ljgfvd.fsf@zagadka.ping.de> <87znuegbw8.fsf@raven.i.defaultvalue.org> <87sn06ek95.fsf@raven.i.defaultvalue.org> <20020919100333.GB7220@www> <8765x2dnum.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 1032448469 29098 127.0.0.1 (19 Sep 2002 15:14:29 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 19 Sep 2002 15:14:29 +0000 (UTC) Cc: rm@fabula.de, Greg Troxel , guile-user@gnu.org Return-path: Original-Received: from monty-python.gnu.org ([199.232.76.173]) by main.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 17s30e-0007Z9-00 for ; Thu, 19 Sep 2002 17:14:28 +0200 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.10) id 17s311-0003Dq-00; Thu, 19 Sep 2002 11:14:51 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17s2yn-00022k-00 for guile-user@gnu.org; Thu, 19 Sep 2002 11:12:33 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17s2yl-00022X-00 for guile-user@gnu.org; Thu, 19 Sep 2002 11:12:32 -0400 Original-Received: from www.elogos.de ([212.18.192.92]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17s2yk-00022B-00 for guile-user@gnu.org; Thu, 19 Sep 2002 11:12:30 -0400 Original-Received: by www.elogos.de (Postfix, from userid 5001) id 256411049B2; Thu, 19 Sep 2002 17:27:59 +0200 (CEST) Original-To: Rob Browning Content-Disposition: inline In-Reply-To: <8765x2dnum.fsf@raven.i.defaultvalue.org> User-Agent: Mutt/1.3.24i Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.11 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:1028 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:1028 On Thu, Sep 19, 2002 at 10:02:25AM -0500, Rob Browning wrote: > rm@fabula.de writes: > > > May i point at similar sugestions i posted a while ago ;-) Libltdl > > does provide API calls to modify the search path at runtime. Why > > don't we extend dynamic linking like this: > > That has the same fundamental problem as setting LD*_LIBRARY_PATH > unless we only modify the value briefly, and *every* time we call > lt_dlopen (still an interesting suggestion). > The problem is that other libraries (or the app linking against > libguile itself) may also put their directories in there, and if, for > example, even one of them puts "/usr/local/lib" at the front after > you've made your modifications, and if there's another "incorrect" > version of some part of guile in /usr/local/lib, then you're likely to > be in trouble the next time you call lt_dlopen. Yes, that's true, but i consider this a problem on a higher level: there _is_ a semantic to the order of places in the search path and guile can't make decisions about that. > > - Putting things in a standard place, or, like Marius phrased it: > > "The right thing is to configure your system so that the installed > > libraries are visible to all programs, in the standard way." > > I can't agree here -- those standard places are meant for libraries > > that can and will be shared by many different applications. > > But libguilereadline is the *only* library for which this isn't the > case. The rest are publically available and it apps are expected to > link directly against them. Hmm, maybe we need a clearer/cleaner distinction between extensions and libraries that other apps are supposed to link against? The code i've written so far always was meant to extend guile or the guile interpreter embedded in an application. I can't really see why any application needs to link against libguilelibxml2.so or libguilegtk-1.2.so.0. > > "what's the true nature of code linked dynamically > > from guile - is it a normal shared library or is it rather a 'plug-in' > > meant to extend an application?" > > As it stands now, the answer is "both". That's one of the main > reasons this problem is hard. For me that sounds like a good reason for making these two things separate issues by using different code. Thanks for all the feedback Ralf _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user