[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: |
Greg Troxel |
Subject: |
Re: Why is Guile now setting LD_LIBRARY_PATH? |
Date: |
Mon, 10 Sep 2012 21:59:04 -0400 |
User-agent: |
Gnus/5.130006 (Ma Gnus v0.6) Emacs/23.4 (berkeley-unix) |
Bruce Korb <address@hidden> 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.
pgpmEwil6xj9c.pgp
Description: PGP signature