Hi Bruce,

Bruce Korb <bk...@gnu.org> 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
       <http://lists.gnu.org/archive/html/guile-devel/2010-11/msg00095.html>
       for details.  */
    augment_env (SHARED_LIBRARY_PATH_VARIABLE, SCM_LIB_DIR);
    augment_env (SHARED_LIBRARY_PATH_VARIABLE, SCM_EXTENSIONS_DIR);

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

Thanks,
Ludo’.


Reply via email to