Bug 438752 - update to new upstream: 1.5.26
update to new upstream: 1.5.26
Product: Fedora
Classification: Fedora
Component: libtool (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Karsten Hopp
Fedora Extras Quality Assurance
Depends On:
  Show dependency treegraph
Reported: 2008-03-24 17:02 EDT by Colin Walters
Modified: 2009-01-28 08:29 EST (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2009-01-28 08:29:05 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Colin Walters 2008-03-24 17:02:46 EDT
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:

Comment 1 Loïc Minier 2008-03-24 17:10:17 EDT
15:17 < walters> hi, can I talk to someone here about this?
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
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@gtk.org, 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
Comment 2 Colin Walters 2008-03-24 17:46:59 EDT
I've updated to 1.5.26 on my machine, and will say if something explodes.
Comment 3 Ivana Varekova 2008-03-26 02:55:13 EDT
*** Bug 438950 has been marked as a duplicate of this bug. ***
Comment 4 Karsten Hopp 2008-04-07 07:56:36 EDT
How about switching to libtool-2.2 ?
Comment 5 Karsten Hopp 2008-04-07 07:58:00 EDT
.. I meant dropping libtool 1.5.x and moving to libtool-2.2 
Comment 6 Colin Walters 2008-04-07 09:24:05 EDT
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.
Comment 7 Bug Zapper 2008-05-14 02:49:06 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
Comment 8 Stepan Kasal 2008-05-20 09:54:53 EDT
BuZapp wrote:
> Changing version to '9'...
Just don't do that.
(Adding keyword FutureFeature to denote this.)
Comment 9 Stepan Kasal 2008-05-20 10:03:48 EDT
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.)
Comment 10 Karsten Hopp 2009-01-28 08:29:05 EST
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.

Note You need to log in before you can comment on or make changes to this bug.