|
From: | Peter O'Gorman |
Subject: | Re: LD_LIBRARY_PATH - disappear of libdir after patch |
Date: | Mon, 12 Mar 2012 22:18:11 -0500 |
User-agent: | Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.22) Gecko/20110906 Fedora/3.1.14-1.fc14 Thunderbird/3.1.14 |
Hi Paul, On 03/12/2012 10:47 AM, Paul Seidler wrote:
Hello, running the test suite of eina-1.1 with 1.0 installed and libtool-2.4{.2,} the tests will fail (symbol lookup errors) because of the LD_LIBRARY_PATH (same with glib, gst-plugins-base, ...). The libdir is in front of the "test-path": LD_LIBRARY_PATH="/usr/lib64:/home/sepek/dev/eina-1.1.0/src/lib/.libs: $LD_LIBRARY_PATH" I don't get this with newer libtool versions (from git), "/usr/lib64:" is no more in LD_LIBRARY_PATH. I traced it down to 06c6555d4a77a5e91f43da3451586534da93e0ae. With a cherry-picked version everything works fine (with 2.4.2) but if I understand the complete message correct it shouldn't affect the functionality of libtool?! At least the tests of libtool throw no error. So my Question: Is this behavior intentional?
That particular patch wasn't supposed to have changed anything, all it's meant to have done is remove quoting where it's not needed.
/usr/lib64 appearing in LD_LIBRARY_PATH is because libtool is brain dead in its detection of "system" library locations. Most vendors have patched their libtools to work around this, e.g.:
http://pkgs.fedoraproject.org/gitweb/?p=libtool.git;a=blob;f=libtool-2.2.10-rpath.patch;h=d0d6d82178642658e6aca5a28d36813158980ca3;hb=HEADPerhaps somehow libtool.m4 bits of your vendor patched libtool are getting used?
Peter
[Prev in Thread] | Current Thread | [Next in Thread] |