Re: Why is Guile now setting LD_LIBRARY_PATH?

[Greg Troxel <gdt@ir.bbn.com>]

[-- Attachment #1: Type: text/plain, Size: 1703 bytes --]


Bruce Korb <bkorb@gnu.org> writes:

> On 09/10/12 16:48, Bruce Korb wrote:
>>> $ guile --version
>>> guile (GNU Guile) 2.0.5
>>> Copyright (C) 2011 Free Software Foundation, Inc.
>> 
>> I added a couple of debug printf's after several hours chasing down
>> why my program was crashing:
>> 
>>> in main() LD_LIBRARY_PATH='EMPTY'
>>> in inner_main() LD_LIBRARY_PATH='/usr/lib64:/usr/lib64/guile/2.0/extensions'
>> 
>> It was crashing because it was linking against a library in /usr/lib64
>> instead of /usr/local/lib64.  Now I know why.
>> 
>> 1.  Why was this done?
>> 2.  Why no notice?  This is *BROKEN*.
>> 
>> 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.)
>> 
>> Distribution:  openSuSE 12.2  (Just in case they are not following your
>> build procedures and I need to harass them.)
>
>
> P.S.  the fix seems to be this, though, naturally, I hate it.
>
> static void
> inner_main(void * closure, int argc, char ** argv)
> {
>     atexit(done_check);
>     initialize(argc, argv);
>
>     {
>         char const * p = getenv("LD_LIBRARY_PATH");
>         if (p != NULL)
>             putenv("LD_LIBRARY_PATH=");
>     }

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.

Also, lib64 is a linuxism; BSDs have the architecture's libs in /usr/lib
and alternate ones in e.g /emul/netbsd32 (such as i386 libs on amd64
machines).  So setting LD_LIBRARY_PATH has to be done in an os and
arch-dependent way, which is complicated.

[-- Attachment #2: Type: application/pgp-signature, Size: 194 bytes --]