Bug 1287191 - Libtool must be rebuilt against new gcc 4.8.5 in rhel 7.2
Libtool must be rebuilt against new gcc 4.8.5 in rhel 7.2
Status: RELEASE_PENDING
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libtool (Show other bugs)
7.2
All All
high Severity high
: rc
: 7.3
Assigned To: Pavel Raiskup
qe-baseos-tools
: ZStream
Depends On:
Blocks: epel7aarch64 epel7ppc64le 1290074
  Show dependency treegraph
 
Reported: 2015-12-01 12:46 EST by Yaakov Selkowitz
Modified: 2016-12-02 12:51 EST (History)
11 users (show)

See Also:
Fixed In Version: libtool-2.4.2-21.el7_2
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1290074 (view as bug list)
Environment:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Patch for rhel-7.3 (960 bytes, patch)
2015-12-01 12:53 EST, Yaakov Selkowitz
no flags Details | Diff

  None (edit)
Description Yaakov Selkowitz 2015-12-01 12:46:17 EST
The version of gcc with which libtool has been built is hard-coded into /usr/bin/libtool, requiring the latter to be rebuilt every time gcc is version-bumped.  In RHEL 7.2, gcc was bumped to 4.8.5 but libtool has yet to be rebuilt.  This prevents packages which use /usr/bin/libtool from being (re)built (e.g. epel7 geos).

Please revbump and rebuild libtool for 7.2.z and 7.3.
Comment 1 Yaakov Selkowitz 2015-12-01 12:51:11 EST
For the purposes of QA, these lines are supposed to prevent this from being missed:

%global gcc_version 4.8.2
[snip]
# /usr/bin/libtool includes paths within gcc's versioned directories
# Libtool must be rebuilt whenever a new upstream gcc is built
Requires: gcc = %{gcc_version}

but for whatever reason, this doesn't seem to help.
Comment 2 Yaakov Selkowitz 2015-12-01 12:53 EST
Created attachment 1100977 [details]
Patch for rhel-7.3

Note that %gcc_version also needs to be adjusted, per this patch.
Comment 3 Pavel Raiskup 2015-12-01 13:52:32 EST
(In reply to Yaakov Selkowitz from comment #0)
> Please revbump and rebuild libtool for 7.2.z and 7.3.

We should really fix this ASAP, thanks for the report (it should have been
done already -- together with gcc).
Comment 4 Dan Horák 2015-12-08 05:45:09 EST
It should out via z-stream if possible.
Comment 10 Tuomo Soini 2015-12-14 03:59:33 EST
Reason for safety check not working can be seen here:

$ rpm -q --provides gcc
bundled(libiberty)
gcc = 4.8.2-16.el7
gcc = 4.8.5-4.el7
gcc(x86-64) = 4.8.5-4.el7
libgcc48privatecloog-isl.so.4()(64bit)
liblto_plugin.so.0()(64bit)

Somebody added Provides: which breaks this safety check.

I suggest using Conflicts: gcc_version + 1

For new build:

Conflicts: gcc >= 4.8.6
Comment 11 Pavel Raiskup 2015-12-14 05:18:28 EST
(In reply to Tuomo Soini from comment #10)
> Reason for safety check not working can be seen here:

Yes, obviously.

> I suggest using Conflicts: gcc_version + 1
> 
> For new build:
> 
> Conflicts: gcc >= 4.8.6

This sounds like good idea.

The process of relevant async errata is probably too far to have it fixed
right now.  I would be OK with respin if QA was OK too.
Comment 12 Yaakov Selkowitz 2015-12-28 16:50:23 EST
(In reply to Tuomo Soini from comment #10)
> Reason for safety check not working can be seen here:
> 
> $ rpm -q --provides gcc
> bundled(libiberty)
> gcc = 4.8.2-16.el7
> gcc = 4.8.5-4.el7
> gcc(x86-64) = 4.8.5-4.el7
> libgcc48privatecloog-isl.so.4()(64bit)
> liblto_plugin.so.0()(64bit)
> 
> Somebody added Provides: which breaks this safety check.

Indeed, although I don't understand why:

%if 0%{?rhel} == 7
%global gcc_version 4.8.2
%else
%global gcc_version 4.8.5
%endif
Version: 4.8.5
Release: %{gcc_release}%{?dist}
%if "%{version}" != "%{gcc_version}"
%define gcc_provides %{gcc_version}-16%{?dist}
%endif
Comment 13 Tuomo Soini 2015-12-28 17:05:14 EST
Note: %rhel == 7.
Comment 14 Yaakov Selkowitz 2015-12-28 23:38:12 EST
(In reply to Tuomo Soini from comment #13)
> Note: %rhel == 7.

Yes, I got *that* part.  I don't understand why this being done in the first place though.
Comment 15 Tuomo Soini 2015-12-29 03:47:36 EST
I can only guess but compatibility with old version is only reason I could guess.
Comment 16 Yaakov Selkowitz 2016-11-04 15:44:11 EDT
RHEL 7.3 shipped with libtool-2.4.2-21.el7_2, which includes this fix.  Can this be closed?

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