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

2012-10-07 Thread Ludovic Courtès
Hi, Mark H Weaver m...@netris.org 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

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

2012-10-06 Thread Mark H Weaver
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)

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

2012-10-06 Thread Ludovic Courtès
Hi, Mark H Weaver m...@netris.org skribis: l...@gnu.org (Ludovic Courtès) writes: Mark H Weaver m...@netris.org 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.

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

2012-10-06 Thread Mark H Weaver
l...@gnu.org (Ludovic Courtès) writes: Mark H Weaver m...@netris.org 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

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

2012-10-05 Thread Sjoerd van Leent Privé
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)

2012-10-05 Thread Mark H Weaver
Sjoerd van Leent Privé svanle...@gmail.com 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

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

2012-10-05 Thread Mark H Weaver
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 m...@netris.org skribis: Following Bruce's

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

2012-10-04 Thread Ludovic Courtès
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 m...@netris.org skribis: Following Bruce's suggestion, it causes 'sysdep_dynl_link' to manually search additional

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

2012-10-03 Thread Mark H Weaver
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