RHEL Engineering is moving the tracking of its product development work on RHEL 6 through RHEL 9 to Red Hat Jira (issues.redhat.com). If you're a Red Hat customer, please continue to file support cases via the Red Hat customer portal. If you're not, please head to the "RHEL project" in Red Hat Jira and file new tickets here. Individual Bugzilla bugs in the statuses "NEW", "ASSIGNED", and "POST" are being migrated throughout September 2023. Bugs of Red Hat partners with an assigned Engineering Partner Manager (EPM) are migrated in late September as per pre-agreed dates. Bugs against components "kernel", "kernel-rt", and "kpatch" are only migrated if still in "NEW" or "ASSIGNED". If you cannot log in to RH Jira, please consult article #7032570. That failing, please send an e-mail to the RH Jira admins at rh-issues@redhat.com to troubleshoot your issue as a user management inquiry. The email creates a ServiceNow ticket with Red Hat. Individual Bugzilla bugs that are migrated will be moved to status "CLOSED", resolution "MIGRATED", and set with "MigratedToJIRA" in "Keywords". The link to the successor Jira issue will be found under "Links", have a little "two-footprint" icon next to it, and direct you to the "RHEL project" in Red Hat Jira (issue links are of type "https://issues.redhat.com/browse/RHEL-XXXX", where "X" is a digit). This same link will be available in a blue banner at the top of the page informing you that that bug has been migrated.
Bug 1988112 - Enable LTO build of libtool for RHEL 9
Summary: Enable LTO build of libtool for RHEL 9
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 9
Classification: Red Hat
Component: libtool
Version: 9.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: 9.0
Assignee: mkulik
QA Contact: Martin Cermak
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2021-07-29 19:24 UTC by Marek Polacek
Modified: 2023-07-18 14:29 UTC (History)
7 users (show)

Fixed In Version: libtool-2.4.6-45.el9
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2022-05-17 13:48:10 UTC
Type: Bug
Target Upstream Version:
Embargoed:
pm-rhel: mirror+

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2022:2589 0 None None None 2022-05-17 13:48:12 UTC

Description Marek Polacek 2021-07-29 19:24:21 UTC 
This package opts out of LTO with this reasoning:    
    
    # The testsuite seems to not properly handle template instantiation and as
    # a result fails.  libtool itself appears to be OK from my by-hand testing.
    # Disable LTO until the testsuite issues are fixed
    %global _lto_cflags %{nil}

It would be nice to track the status of these failures and potentially re-enable LTO if/when possible.  To that effect, I'm opening this BZ.  If you decide that LTO is not worth the effort for this package, feel free to close as WONTFIX.

Thanks!

See also:
  https://issues.redhat.com/browse/RHELPLAN-54371
  https://issues.redhat.com/browse/RHELBU-522
Comment 1 Ondrej Dubaj 2021-08-18 06:26:46 UTC 
The testsuite is still failing when LTO is enabled. I will try to talk to upstream about this issue.
Comment 2 Ondrej Dubaj 2021-08-18 10:26:11 UTC 
Upsteam issue:

https://lists.gnu.org/archive/html/bug-libtool/2021-08/msg00001.html
Comment 3 Ondrej Dubaj 2021-09-16 09:52:25 UTC 
No response from upstream yet.
Comment 4 mkulik 2021-11-02 22:01:41 UTC 
Still no response from upstream. I decided to look into this. Here is short explanations for this issue:

LTO build seems to be completely fine, no problems during normal usage. We'll only see issues during test check, few testcases will fail when we try to build libtool with LTO, to be precise in these two:

67: Link order of deplibs                           FAILED (link-order2.at:125)
170: Run tests with low max_cmd_len                  FAILED (cmdline_wrap.at:47)

Number 170 is not a failure caused by LTO. This test is just a repetition of all other tests with changed max_cmd_len, any other test failure will cause test to fail too (most likely).
The only problem here is test number 67. Here is link to discussion of the origin for this test: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=391427
I didn't dig too deep into this but this failure is not related directly to LTO build of libtool. Here is what actually is causing this failure:

Compiler flags for this test (and most likely for rest of them) are inherited from actual build phase. (I'm not sure if this is expected but probably not)

Here is example of CFLAGS from current build process:
CFLAGS='-O2 -flto=auto -ffat-lto-objects -fexceptions -g -grecord-gcc-switches -pipe -Wall -Werror=format-security -Wp,-D_FORTIFY_SOURCE=2 -Wp,-D_GLIBCXX_ASSERTIONS  -specs=/usr/lib/rpm/redhat/redhat-annobin-cc1  -m64  -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -fPIC'

Flags responsible for LTO '-flto=auto -ffat-lto-objects' will be used in this test only when we specify them in build process. This test will always fail with those flags, regardless of LTO or not-LTO build.

TLDR: This issue is not related to libtool LTO build but to usage of LTO flags in testcases and/or correct handling them.
Comment 5 mkulik 2021-11-30 12:11:39 UTC 
Build in testing in Fedora: https://bodhi.fedoraproject.org/updates/FEDORA-2021-6e9c836c28

It can be merge to RHEL9 at later date if there are no issues.
Comment 14 errata-xmlrpc 2022-05-17 13:48:10 UTC 
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (new packages: libtool), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2022:2589
Note You need to log in before you can comment on or make changes to this bug.