Hi, Debian has been complaining that Fedora ships an old libtool which uses rpaths on lib64 systems. We should update to the newest upstream, which resolves this issue: http://ftp.gnu.org/gnu/libtool/libtool-2.2.tar.gz
15:17 < walters> hi, can I talk to someone here about this? http://wiki.debian.org/RpathIssue 15:17 < walters> what's the status with respect to libtool upstream on this? 15:18 < walters> is it really expected that all upstream projects copy and paste matthew's snippet into their configure.ac? ... 21:52 <@lool> walters: Can we talk about rpath? 21:53 < walters> lool: yeah, i spent a while this morning trying to figure out what the state of things was with that 21:53 <@lool> walters: So basically upstream fixed handling of Debian's choice to use /usr/lib on amd64 21:53 < walters> ah, so debian doesn't have a patched version anymore? ... 21:54 <@lool> walters: However, it seems Fedora's libtool might still be shipping a snippet which tells libtool that /usr/lib64 is the only library path in amd-4 21:54 <@lool> amd64 21:54 < walters> what version of libtool do you have? 21:54 <@lool> walters: Of libtool? We might have other patches, but I'm pretty sure it's completely fixed upstream now 21:54 < walters> i'm building software using libtool-1.5.24-3.fc8 21:54 <@lool> We have 1.5.26-1 in sid and 2.1a+cvs1.2525+20071016-1 in experimental 21:55 < walters> ok, quite possible fedora doesn't have the udpate yet 21:55 <@lool> Let me check 21:56 < walters> looks like we still have 1.5.24-multilib.patch 21:56 <@lool> - Search paths with GCC on multilib systems like x86_64 have been fixed. 21:57 < walters> i'll see if i can poke the fedora maintainer to update 21:57 < walters> or just do it myself ... 21:57 <@lool> BUt that's old ... 21:57 <@lool> walters: Could you check whether you have a patch that set lib64 in some way? ... 21:57 < walters> lool: in libtool? 21:57 <@lool> walters: Yes 21:57 < walters> yeah, looks like we still have 1.5.24-multilib.patch 21:58 < walters> though, no lib64 matches in there 21:58 <@lool> walters: is it setting libdir to lib64? 21:58 < walters> ah, 21:58 < walters> *64-bit*) 21:58 < walters> + libsuff=64 21:58 <@lool> Right, that's the problem 21:58 <@lool> walters: It's creating a *huge* pain for Debian now 21:59 <@lool> walters: Because some upstream's release running Fedora 21:59 < walters> right 21:59 <@lool> And then our binaries end up with RPATH /usr/lib 21:59 < walters> someday, we'll toss all this shell script garbage and use a real build system =) 21:59 <@lool> Because libtool thinks /usr/lib64 and only that is in the lib path 21:59 <@lool> And on amd64, it means we can't use LD_LIBRARY_PATH on binaries anymore ... 22:00 < walters> hm, upstream is on 2.2 22:00 <@lool> Right 22:00 <@lool> walters: It would be excellent if you could get rid of the fedora lib64 forcing, but perhaps you need a new upstream for this 22:01 < walters> lool: i'm not sure i want to try to do this right now...we're trying to do a release, but I'll make something happen after f9 22:01 <@lool> walters: Ok; as you imagine, the scale of this problem is HUGE, so I'd appreciate if you could keep this IRC log high on your TODO ;) 22:01 < walters> yep 22:01 <@lool> walters: But a couple of weeks wont make a big difference obviously 22:01 <@lool> walters: thanks! 22:02 < walters> lool: do you have a bugzilla.redhat.com account? 22:03 < walters> anyways i filed https://bugzilla.redhat.com/show_bug.cgi?id=438752 22:03 < bugbot> Bug 438752: normal, Normal, ---, gtk-bugs, UNCONFIRMED, clipped text in about dialogue 22:03 <@lool> walters: I do 22:04 <@lool> I'll tell you once my browser comes back, sigh ... 22:08 <@lool> walters: May I copy our log to the bug? 22:08 < walters> lool: yep
I've updated to 1.5.26 on my machine, and will say if something explodes.
*** Bug 438950 has been marked as a duplicate of this bug. ***
How about switching to libtool-2.2 ?
.. I meant dropping libtool 1.5.x and moving to libtool-2.2
I tried updating my local package, but the soname for libdl changed in 2.2, so we'd need to call the package libtool2 most likely. Updating to the latest 1.5.26 would resolve the issue the Debian people were complaining about, and should be a simple upgrade.
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
BuZapp wrote: > Changing version to '9'... Just don't do that. (Adding keyword FutureFeature to denote this.)
Sorry, returning back to Fedora 9. Let's keep this one as a suggestion to update to 1.5.26 in Fedora 9. (There is bug #435737 proposing upgrade to 2.2 in rawhide.)
I'd rather not break anything with a libtool-2.2 update in f-9. If someone absolutely needs it and can't wait for F-11, a recompile of the rawhide package is done in a couple of minutes.