[Top][All Lists]

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

Re: Why is Guile now setting LD_LIBRARY_PATH?

From: Ludovic Courtès
Subject: Re: Why is Guile now setting LD_LIBRARY_PATH?
Date: Tue, 11 Sep 2012 15:12:52 +0200
User-agent: Gnus/5.130005 (Ma Gnus v0.5) Emacs/24.2 (gnu/linux)

Hi Bruce,

Bruce Korb <address@hidden> skribis:

>> 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 SCM_EXTENSIONS_DIR to the loader's search
       path.  `lt_dladdsearchdir' and $LTDL_LIBRARY_PATH can't be used
       for that because they are searched before the system-dependent
       search path, which is the one `libtool --mode=execute -dlopen'
       fiddles with (info "(libtool) Libltdl Interface").  See
       for details.  */

> 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?


reply via email to

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