guile-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [PATCH] Don't augment LD_LIBRARY_PATH (was Re: [PATCH] do not augmen


From: Ludovic Courtès
Subject: Re: [PATCH] Don't augment LD_LIBRARY_PATH (was Re: [PATCH] do not augment environment)
Date: Sat, 06 Oct 2012 14:42:54 +0200
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)

Hi,

Mark H Weaver <address@hidden> skribis:

> address@hidden (Ludovic Courtès) writes:
>> Mark H Weaver <address@hidden> 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’t solve the problem described at
>> <http://lists.gnu.org/archive/html/guile-devel/2010-11/msg00095.html>,
>> right?
>>
>> To solve it, we’d have to do our own lookup unconditionally.

[...]

> As I understand it, the reason given for why we cannot use that approach
> is that 'libtool --mode=execute -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, because that’s the Libtool way to say “hey, load this
particular file, not one that may be found in the search path.”
See, for example,
<http://git.savannah.gnu.org/cgit/gnutls.git/tree/guile/pre-inst-guile.in>.

So the goal is to keep that working.

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.

How does that sound?

(BTW, the above message was followed-up at
<http://lists.gnu.org/archive/html/guile-devel/2011-02/msg00075.html>.)

Thanks,
Ludo’.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]