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 12:03:33 +0200 Sender: guile-user-admin@gnu.org Message-ID: <20020919100333.GB7220@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> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1032428954 29384 127.0.0.1 (19 Sep 2002 09:49:14 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 19 Sep 2002 09:49:14 +0000 (UTC) Cc: 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 17rxvs-0007dm-00 for ; Thu, 19 Sep 2002 11:49:12 +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 17rxw6-0000vr-00; Thu, 19 Sep 2002 05:49:26 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17rxut-0000nw-00 for guile-user@gnu.org; Thu, 19 Sep 2002 05:48:11 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17rxuq-0000iY-00 for guile-user@gnu.org; Thu, 19 Sep 2002 05:48:11 -0400 Original-Received: from www.elogos.de ([212.18.192.92]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17rxuq-0000do-00 for guile-user@gnu.org; Thu, 19 Sep 2002 05:48:08 -0400 Original-Received: by www.elogos.de (Postfix, from userid 5001) id 0A1931049B2; Thu, 19 Sep 2002 12:03:33 +0200 (CEST) Original-To: Rob Browning Content-Disposition: inline In-Reply-To: <87sn06ek95.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:1020 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:1020 On Wed, Sep 18, 2002 at 10:22:30PM -0500, Rob Browning wrote: > prj@po.cwru.edu (Paul Jarc) writes: > > > By "temporarily", I meant that the modification should be undone > > after linking the library. Would this problem still remain then? > > Hmm, that's an interesting idea. It might be shaky in the presence of > threads, but I'm not sure that's something we're aiming to accomodate. > It would also prevent users from controlling things via their normal > envt, vars, but perhaps that's not critical either. It's definitely > better than what I had been thinking in that direction. 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: static void * sysdep_dynl_link (const char *fname, const char *subr) { lt_dlhandle handle; const char *orig_path; const char *guile_libdir = SCM_PKGLIB_DIR "/lib" /* save original search path */ orig_path = lt_dlgetsearchpath(); /* modify for guile usage - * NOTE: we might want to _prepend_ here instead of just adding, * this would require some string operations and a call to * 'lt_dlsetsearchpath()' instead the following ... */ void lt_dladdsearchdir(guile_libdir); handle = lt_dlopenext (fname); if (NULL == handle) { SCM fn; SCM msg; fn = scm_makfrom0str (fname); msg = scm_makfrom0str (lt_dlerror ()); scm_misc_error (subr, "file: ~S, message: ~S", scm_list_2 (fn, msg)); } /* restore original search path */ void lt_dlsetsearchpath(orig_path); return (void *) handle; } A few remarks (even so i might repeat myself): - Multithreading: libltdl _does_ provide a mutex framework - iff we need threadsave dynamic linking we "just" need to implement the mutex/locking code (BTW, i don't see where this is different from the current aproach - we need to have mutexes too [see the comment at the beginning of file 'dynl.c']). - 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. Object code like guilereadline.so isn't meant to be of any use to non-guile applications (and in the few cases an application really needs to dynamiclly link against such objects we should assume that the programmer knew what she is doing and expect her to add our guile specific library location(s) to the search path). I think one can reduce this discussion to the question: "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?" I tend to favour the second view. Looking at other interpreters (shudder): both perl and python (as well as some more esotheric languages) have their "private" library space. > However, I guess at the moment, since we have the issue documented in > the INSTALL file, I'm tempted to leave things alone until we can > hopefully figure out a more general solution (during the 1.7 > development cycle), and then only change things once. I don't really see what the solution i suggested would break that wouldn't break with the solution mentioned in the INSTALL file. Modifying the environment will affect the linking behaviour of the application as a whole _and_ will change the linking behaviour of all child processes -- not really an option for many uses. > Marius has suggested that perhaps the right thing to do is discuss > this with the libltdl people and see if we can settle on a more > general solution, one that might also involve a versioned lt_dlopen. > I'm inclined in that direction as well. Yes, i think this is a good idea (and, given the number of problem reports in this list alone, probably needs to be done soon). Ralf Mattes _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user