From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Mark H Weaver Newsgroups: gmane.lisp.guile.devel Subject: Re: [PATCH] Don't augment LD_LIBRARY_PATH (was Re: [PATCH] do not augment environment) Date: Sat, 06 Oct 2012 10:31:03 -0400 Message-ID: <87ehlblljs.fsf@tines.lan> References: <505CF9FC.9060007@gmail.com> <5069022C.9040600@netris.org> <87y5jnn8y4.fsf_-_@tines.lan> <877gr6j7ml.fsf@gnu.org> <87mx00mixi.fsf@tines.lan> <87bogf7ovl.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1349533884 24204 80.91.229.3 (6 Oct 2012 14:31:24 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Oct 2012 14:31:24 +0000 (UTC) Cc: Bruce Korb , guile-devel@gnu.org To: ludo@gnu.org (Ludovic =?utf-8?Q?Court=C3=A8s?=) Original-X-From: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Sat Oct 06 16:31:30 2012 Return-path: Envelope-to: guile-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1TKVPe-0003oX-5u for guile-devel@m.gmane.org; Sat, 06 Oct 2012 16:31:30 +0200 Original-Received: from localhost ([::1]:35748 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKVPX-0006LO-Ux for guile-devel@m.gmane.org; Sat, 06 Oct 2012 10:31:23 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:45295) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKVPU-0006LJ-W1 for guile-devel@gnu.org; Sat, 06 Oct 2012 10:31:22 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKVPT-0002e3-LW for guile-devel@gnu.org; Sat, 06 Oct 2012 10:31:20 -0400 Original-Received: from world.peace.net ([96.39.62.75]:46597) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKVPT-0002dz-Fz; Sat, 06 Oct 2012 10:31:19 -0400 Original-Received: from 209-6-91-212.c3-0.smr-ubr1.sbo-smr.ma.cable.rcn.com ([209.6.91.212] helo=tines.lan) by world.peace.net with esmtpsa (TLS1.0:DHE_RSA_AES_128_CBC_SHA1:16) (Exim 4.72) (envelope-from ) id 1TKVPK-0007x6-VT; Sat, 06 Oct 2012 10:31:11 -0400 In-Reply-To: <87bogf7ovl.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Sat, 06 Oct 2012 14:42:54 +0200") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.2 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-Received-From: 96.39.62.75 X-BeenThere: guile-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Developers list for Guile, the GNU extensibility library" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Original-Sender: guile-devel-bounces+guile-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.devel:14935 Archived-At: ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> As I understand it, the reason given for why we cannot use that approach >> is that 'libtool --mode=3Dexecute -dlopen' would not work properly, > > Exactly. > >> but why do we have to do it that way? > > It is a fact that some projects (at least some of mine) have been using > that idiom, Do these projects also set GUILE_SYSTEM_EXTENSIONS_PATH? > because that=E2=80=99s the Libtool way to say =E2=80=9Chey, load this > particular file, not one that may be found in the search path.=E2=80=9D I would refine this to "load this particular file, not one that may be found in LD_LIBRARY_PATH or the default system library search paths, *unless* the library is found in either LTDL_LIBRARY_PATH or in some path added via 'lt_dladdsearchdir' et al." In other words, libtool's own preferred mechanism for programs to augment their internal search paths gives those internal paths priority over the files specified by 'libtool --mode=3Dexecute -dlopen'. So it seems to me that either this is a bug in libtool that should be fixed, or it is not appropriate to expect this idiom to override a program's extensions. Having said that, I acknowledge that the existence of programs that depend upon this idiom to override Guile's SCM_EXTENSIONS_DIR force us to accommodate them somehow, at least in 2.0. > Ideally, I would accept any solution that (1) gets rid of the > LD_LIBRARY_PATH export, and (2) can be shown with strace to preserve the > extension search order. As I pointed out in my recent followup, the current extension search order is fundamentally broken, because in the common case of SCM_LIB_DIR=3D/usr/lib, it typically puts /usr/lib before /usr/local/lib in the search path. This will cause problems for users that depend upon /usr/local/lib preceding /usr/lib when loading libraries from Guile. Therefore, I don't think we should try to exactly preserve the current broken search order. At the very least, I think we need to avoid adding SCM_LIB_DIR anywhere other than as a last resort (which means a manual search), and perhaps not even then. For SCM_EXTENSIONS_DIR, if we need to allow programs to override it using 'libtool --mode=3Dexecute -dlopen' (and without setting GUILE_SYSTEM_EXTENSIONS_PATH) then I guess the only good option is to manually search for SCM_EXTENSIONS_DIR after all else has failed. Does that make sense? The one remaining question is where to put a non-empty GUILE_SYSTEM_EXTENSIONS_PATH in the library search paths. It's hard for me to answer that question without knowing how this variable is supposed to be used. It's not documented, but its name suggests that it should override the value of SCM_EXTENSIONS_DIR, and therefore be put where SCM_EXTENSIONS_DIR would have been put. To my mind, a sensible use for this variable is to allow the user to place Guile extensions in directories other than $(libdir)/guile/2.0/extensions/, for example somewhere within their home directory. So a user might reasonably set this variable in their shell startup files. However, if they set the variable to anything at all, then they would also need to include $(libdir)/guile/2.0/extensions/ somewhere within it. If we want your idiom to override that directory, then GUILE_SYSTEM_EXTENSIONS_PATH also needs to be placed where SCM_EXTENSIONS_DIR would have been put. I realize that backward compatibility is important, but it's also important to fix broken behavior and improve things over time, when it can be done without significantly burdening users in practice. What do you think? Mark