Bug 1287191 - Libtool must be rebuilt against new gcc 4.8.5 in rhel 7.2
Summary: Libtool must be rebuilt against new gcc 4.8.5 in rhel 7.2
Keywords:
Status: CLOSED WONTFIX
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libtool
Version: 7.2
Hardware: All
OS: All
high
high
Target Milestone: rc
: 7.3
Assignee: Patrik Novotný
QA Contact: qe-baseos-tools-bugs
URL:
Whiteboard:
Depends On:
Blocks: epel7ppc64le epel7aarch64 1290074
TreeView+ depends on / blocked
 
Reported: 2015-12-01 17:46 UTC by Yaakov Selkowitz
Modified: 2020-12-15 07:38 UTC (History)
11 users (show)

Fixed In Version: libtool-2.4.2-21.el7_2
Doc Type: Bug Fix
Doc Text:
Clone Of:
: 1290074 (view as bug list)
Environment:
Last Closed: 2020-12-15 07:38:54 UTC
Target Upstream Version:


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

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.


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