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: Fri, 05 Oct 2012 22:30:01 -0400 Message-ID: <87mx00mixi.fsf@tines.lan> References: <505CF9FC.9060007@gmail.com> <5069022C.9040600@netris.org> <87y5jnn8y4.fsf_-_@tines.lan> <877gr6j7ml.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 1349490628 23308 80.91.229.3 (6 Oct 2012 02:30:28 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 6 Oct 2012 02:30:28 +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 04:30:32 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 1TKK9t-0003K6-6a for guile-devel@m.gmane.org; Sat, 06 Oct 2012 04:30:29 +0200 Original-Received: from localhost ([::1]:56494 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKK9m-00009s-RJ for guile-devel@m.gmane.org; Fri, 05 Oct 2012 22:30:22 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:33310) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKK9k-00007z-OT for guile-devel@gnu.org; Fri, 05 Oct 2012 22:30:21 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1TKK9j-0006UI-HW for guile-devel@gnu.org; Fri, 05 Oct 2012 22:30:20 -0400 Original-Received: from world.peace.net ([96.39.62.75]:45875) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1TKK9j-0006SZ-D2; Fri, 05 Oct 2012 22:30: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 1TKK9Z-0006x4-2P; Fri, 05 Oct 2012 22:30:09 -0400 In-Reply-To: <877gr6j7ml.fsf@gnu.org> ("Ludovic \=\?utf-8\?Q\?Court\=C3\=A8s\=22'\?\= \=\?utf-8\?Q\?s\?\= message of "Thu, 04 Oct 2012 22:37: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:14931 Archived-At: Hi Ludovic! Thanks for the review. I agree with your stylistic suggestions and will update my patch accordingly. What I'd like to discuss here is the logic of the library search order. ludo@gnu.org (Ludovic Court=C3=A8s) writes: > Mark H Weaver skribis: > >> Following Bruce's suggestion, it causes 'sysdep_dynl_link' to manually >> search additional directories if 'lt_dlopenext' fails to find the >> library in the default paths. > > Thus, that doesn=E2=80=99t solve the problem described at > , > right? > > To solve it, we=E2=80=99d have to do our own lookup unconditionally. I've read the message referenced above several times, but I've failed to understand why we cannot use 'lt_dladdsearchdir' to augment the path, as shown in the first code excerpt of that message: --8<---------------cut here---------------start------------->8--- env =3D getenv ("GUILE_SYSTEM_EXTENSIONS_PATH"); [...] if (env) lt_dladdsearchdir (env); else { lt_dladdsearchdir (SCM_LIB_DIR); lt_dladdsearchdir (SCM_EXTENSIONS_DIR); } --8<---------------cut here---------------end--------------->8--- (although I would enhance that code to properly handle multiple path components in GUILE_SYSTEM_EXTENSIONS_PATH). As I understand it, the reason given for why we cannot use that approach is that 'libtool --mode=3Dexecute -dlopen' would not work properly, but why do we have to do it that way? Within 'meta/uninstalled-env', why not set GUILE_SYSTEM_EXTENSIONS_PATH to point to the libraries and extensions in the build directory? In fact, you seem to suggest that fix near the end the Nov 2010 message referenced above. Why was that solution not adopted? Thanks, Mark