Re: Why is Guile now setting LD_LIBRARY_PATH?

[Bruce Korb]

Hi Ludo,
>> in main() LD_LIBRARY_PATH='EMPTY'
>> in inner_main() LD_LIBRARY_PATH='/usr/lib64:/usr/lib64/guile/2.0/extensions'
>
>The reason provided in ‘sysdep_dynl_init’ is:
>
>/* Add SCM_LIB_DIR and ... See
>   <http://lists.gnu.org/archive/html/guile-devel/2010-11/msg00095.html>
>   for details. */

I am sure you are not arguing that I ought to have known due to a comment
in source code and an email from a couple of years ago.  My point is that
messing with the library search path in an effectively secret manner
caused me to spend hours chasing the problem.

>> libguile needs to be linked with -Wl,-rpath
>> -Wl,/usr/lib64/guile/2.0/extensions
>> instead of messing up your client's link/load. ("/usr/lib64" should not be
>> needed.)
>
>Problem is that (1) -rpath is not always available, and (2) when using
>GNU ld with --enable-new-dtags, it produces a RUNPATH (not an RPATH),
>which can be overridden by $LD_LIBRARY_PATH.
>
>I agree that using setenv is ugly, but finding an option that’s portable
>and doesn’t break existing programs seems tricky too.
>
>Do you have any solutions meeting this criteria in mind?

Wrap your dlopen's in code that pushes the needed values to the environment
and then removes them when dlopen is done.  You still have multi-thread
issues when someone is calling dlopen or exec while a libguile thread
is messing with the environment.  Perhaps you could document a global
lock variable that could single-thread these operations for multi-threaded
applications.  Either way, fiddling the environment only while using dlopen
is far better than breaking people's applications in unexpected ways.

At the end:  messing with LD_LIBRARY_PATH in a library breaks programs
that use the library and make calls to exec or dlopen.  Please find
a solution that does not do this, or at least minimizes the issues.

Thank you.  Regards, Bruce

C.F. Greg Troxel:
> I don't follow why you think this is the right fix.  It seems that guile
>  (main) and libguile (library) should both not set LD_LIBRARY_PATH at
> all.
To be clear, I do not think this the right fix, but since my application has to
cope with un-fixed guile releases, I have to do something.  Nuking the
variable is the easiest.   WRT guile the program and libguile the library, you
are correct:  neither should set LD_LIBRARY_PATH.  It needs to be a
user selection to adjust to specific issues in a user's environment.