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