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

[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.

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.

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 = 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=execute -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