From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Greg Troxel Newsgroups: gmane.lisp.guile.user Subject: Re: 1.6.0 problems with libguilereadline-v-12 and fix Date: 19 Sep 2002 09:43:44 -0400 Sender: guile-user-admin@gnu.org Message-ID: References: <20020918203311.3C5FA3F28@fnord.ir.bbn.com> <87k7ljgfvd.fsf@zagadka.ping.de> NNTP-Posting-Host: localhost.gmane.org X-Trace: main.gmane.org 1032443058 7003 127.0.0.1 (19 Sep 2002 13:44:18 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Thu, 19 Sep 2002 13:44:18 +0000 (UTC) Cc: 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 17s1bL-0001oX-00 for ; Thu, 19 Sep 2002 15:44:15 +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 17s1bf-0000zv-00; Thu, 19 Sep 2002 09:44:36 -0400 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.10) id 17s1av-0000fV-00 for guile-user@gnu.org; Thu, 19 Sep 2002 09:43:49 -0400 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.10) id 17s1ar-0000f7-00 for guile-user@gnu.org; Thu, 19 Sep 2002 09:43:48 -0400 Original-Received: from fnord.ir.bbn.com ([192.1.100.210]) by monty-python.gnu.org with esmtp (Exim 4.10) id 17s1ar-0000f2-00 for guile-user@gnu.org; Thu, 19 Sep 2002 09:43:45 -0400 Original-Received: by fnord.ir.bbn.com (Postfix, from userid 10853) id 06DAC3F29; Thu, 19 Sep 2002 09:43:45 -0400 (EDT) Original-To: Marius Vollmer In-Reply-To: Marius Vollmer's message of "18 Sep 2002 23:14:14 +0200" Original-Lines: 87 X-Mailer: Gnus v5.7/Emacs 20.7 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:1023 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:1023 I'll try to step back and take a broader look - there are multiple issues here. 1) 'Shared libraries' and guile's dlopening of libguilereadline-v-12 are not the same thing. A normal usage of a shared library involves link-time binding of the library to the binary. For example, the guile binary refers to libguile.so.15 and libltdl.so.4. The search paths for resolving these libraries at run-time is given by '-R' linker options, at least on BSD. Thus, these libraries can be found in the appropriate place at runtime without having to set environment variables. Further, I believe that programs linked against different versions of libguile.so.15 will each find the right one, due to the differing -R options at link time. dlopening does not use this link-time binding. (perhaps on NetBSD the -R values are being used by dlopen 2) On BSD ELF systems, it is my opinion that having to have set LD_LIBRARY_PATH is a sign of underlying brokenness. I have not had to do this other than guile. So it's a warning sign that guile seems to require setting this variable. 3) Stepping back from shared library issues and assuming we have infinitely wonderful support, consider the correct behavior. Guile installs a bunch of .scm files and a bunch of .so files that libguile uses for various purposes. The guile installation is a complete set, and it doesn't make much sense to mix and match files between installations. If one has multiple copies of 1.6 (perhaps some hacked up in various ways) installed, each guile binary in /usr/guile16-foo/bin should get the corresponding /usr/guile16-foo/share/guile/1.6.0/ice-9/*.scm and /usr/guile16-foo/lib/libguilereadline-v-12 dynamic object (similarly for /usr/guile16-bar). Looking anyplace else for this shared object, like /usr/bin, or /usr/local/bin, is simply the wrong thing to do - the build did not put it there and any such files are either cruft or part of a different build of guile. It would be equally broken to link in /usr/lib/libguilereadline-v-12.so as it would be for /usr/guile16-foo/bin/guile to read ice-9 stuff from /usr/share/guile/1.6.0/ice-9. (One can argue for looking for modules in other places, but that's a different story from things that are "part of guile"). I don't understand the notion of prepending $(libdir) to the search path as the right answer; this will still look in other places, and I think it is incorrect to even try those other places for files that are part of guile. 4) Setting LD_LIBRARY_PATH can't work in general. If one had two guile installations in /usr/guile16-{foo,bar}, one of the lib dirs has to come first. The other installation will dlopen the wrong .so files. 5) LD_LIBRARY_PATH doesn't work in setuid/setgid situations. Guile should not foreclose this option. In general, I think the -R concept for shared libraries has been a big win - library locations get bound into the dynamic executable, rather than having system changes over time cause libraries in different directories to get loaded. So I freely admit that this biases my opinions. If one accepts my point 3, then it follows that guile should try to dlopen libguilereadline-v-12.so from _exactly one place_, the place where the guile build put it. So I argue that using any sort of search path is incorrect for these objects. Thus, I think we need a new procedure that takes an absolute pathname of a .so and dlopens it without doing any search operations, and should call that with the libdir value from the build-time configuration. Passing the absolute path to the current procedure appears to more-or-less do this, although it might search for /usr/lib/usr/foo/lib/libguilereadline-v-12. With this absolute-path scheme, guile and guile-using-applications will work correctly without needing to set any environment variables. It looks like libltdl:try_dlopen needs only to check if the first character is / and then not do the searching steps in order to fully implement the above scheme. I don't think there are any downsides to the try-exactly-one-place approach, other than perhaps having to modify libltdl to really implement it. AFAIK, guile already does not support the notion of putting the bits in other than the prefix they were built for. Greg Troxel _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user