Bug 1287191

Summary: Libtool must be rebuilt against new gcc 4.8.5 in rhel 7.2
Product: Red Hat Enterprise Linux 7 Reporter: Yaakov Selkowitz <yselkowi>
Component: libtoolAssignee: Patrik Novotný <panovotn>
Status: CLOSED WONTFIX QA Contact: qe-baseos-tools-bugs
Severity: high Docs Contact:
Priority: high    
Version: 7.2CC: dhorak, hannsj_uhl, hhorak, jfeeney, jpopelka, mcermak, orion, ovasik, praiskup, tis, yselkowi
Target Milestone: rcKeywords: ZStream
Target Release: 7.3   
Hardware: All   
OS: All   
Whiteboard:
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: 2020-12-15 07:38:54 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1197165, 1285484, 1290074    
Attachments:
Description Flags
Patch for rhel-7.3 none

Description Yaakov Selkowitz 2015-12-01 17:46:17 UTC
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 17:51:11 UTC
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 17:53:31 UTC
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 18:52:32 UTC
(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 10:45:09 UTC
It should out via z-stream if possible.

Comment 10 Tuomo Soini 2015-12-14 08:59:33 UTC
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 10:18:28 UTC
(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 21:50:23 UTC
(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 22:05:14 UTC
Note: %rhel == 7.

Comment 14 Yaakov Selkowitz 2015-12-29 04:38:12 UTC
(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 08:47:36 UTC
I can only guess but compatibility with old version is only reason I could guess.

Comment 16 Yaakov Selkowitz 2016-11-04 19:44:11 UTC
RHEL 7.3 shipped with libtool-2.4.2-21.el7_2, which includes this fix.  Can this be closed?

Comment 18 RHEL Program Management 2020-12-15 07:38:54 UTC
After evaluating this issue, there are no plans to address it further or fix it in an upcoming release.  Therefore, it is being closed.  If plans change such that this issue will be fixed in an upcoming release, then the bug can be reopened.