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

Hi, Mark H Weaver skribis: > I wrote: >> 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: >> >> env = getenv ("GUILE_SYSTEM_EXTENSIONS_PATH");

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

l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> 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 proj

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

Hi, Mark H Weaver skribis: > l...@gnu.org (Ludovic Courtès) 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 do

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

I wrote: > 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: > > env = getenv ("GUILE_SYSTEM_EXTENSIONS_PATH"); > > [...] > > if (env) > lt_

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

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. l...@gnu.org (Ludovic Courtès) writes: > Mark H Weaver skribis: > >> Following Bruce's suggestion, it causes

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

Sjoerd van Leent Privé writes: > Just a quick note. Now with GUILE_SYSTEM_EXTENSIONS_PATH, this could > be very practical when developing a module. However, if a module is > already present AND is inside SCM_LIB_DIR or SCM_EXTENSIONS_DIR, it > would never override that situation. I believe there s

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

Hi Mark, Just a quick note. Now with GUILE_SYSTEM_EXTENSIONS_PATH, this could be very practical when developing a module. However, if a module is already present AND is inside SCM_LIB_DIR or SCM_EXTENSIONS_DIR, it would never override that situation. I believe there should be a way to be able

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

Hi Mark! Thanks for being quicker and more active than me! ;-) Overall, the approach of mimicking what the lookup procedure of ‘lt_dlopenext’ sounds good to me. Mark H Weaver skribis: > Following Bruce's suggestion, it causes 'sysdep_dynl_link' to manually > search additional directories if '

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

Hello all, Here's a preliminary patch to avoid modifying LD_LIBRARY_PATH. 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. However, I took a somewhat different approach, and trie

Re: [PATCH] do not augment environment

On 10/01/12 09:59, Mark H Weaver wrote: > On 10/01/2012 10:39 AM, Bruce Korb wrote: >> On 09/30/12 19:38, Mark H Weaver wrote: >>> In the current code, SCM_LIB_DIR and SCM_EXTENSIONS_DIR are only >>> added to the library search path when GUILE_SYSTEM_EXTENSIONS_PATH >>> is not set. Your patch mish

Re: [PATCH] do not augment environment

On 10/01/2012 10:39 AM, Bruce Korb wrote: On 09/30/12 19:38, Mark H Weaver wrote: In the current code, SCM_LIB_DIR and SCM_EXTENSIONS_DIR are only added to the library search path when GUILE_SYSTEM_EXTENSIONS_PATH is not set. Your patch mishandles this, because it _always_ acts as if SCM_LIB_DI

Re: [PATCH] do not augment environment

Hi, P.S. On 09/30/12 19:38, Mark H Weaver wrote: > In the current code, SCM_LIB_DIR and SCM_EXTENSIONS_DIR are only > added to the library search path when GUILE_SYSTEM_EXTENSIONS_PATH > is not set. Your patch mishandles this, because it _always_ acts > as if SCM_LIB_DIR and SCM_EXTENSIONS_DIR h

Re: [PATCH] do not augment environment

Hi Mark, On 09/30/12 19:38, Mark H Weaver wrote: > Thanks for the patch, but I think it needs more work before it can be > committed. See below for my comments. You're welcome! Just FYI, I've got no ego wrapped up in being the one to type in characters, so fixing things up for preferred style o

Re: [PATCH] do not augment environment

Hi Bruce, Thanks for the patch, but I think it needs more work before it can be committed. See below for my comments. diff --git a/libguile/dynl.c b/libguile/dynl.c index 72305a4..999627a 100644 --- a/libguile/dynl.c +++ b/libguile/dynl.c @@ -81,7 +81,25 @@ sysdep_dynl_link (const char *fname,

Re: [PATCH] do not augment environment

Thank you for looking into the patch. Could you give me an idea as to when it will be in a release? Thank you so much! Regards, Bruce