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: RELEASE_PENDING
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
URL:
Whiteboard:
Depends On:
Blocks: epel7aarch64 epel7ppc64le 1290074
TreeView+ depends on / blocked
 
Reported: 2015-12-01 17:46 UTC by Yaakov Selkowitz
Modified: 2019-08-31 19:46 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:


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?


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