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 1634784 - python3 hard-codes annobin usage
Summary: python3 hard-codes annobin usage
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 8
Classification: Red Hat
Component: python3
Version: 8.0
Hardware: Unspecified
OS: Unspecified
low
low
Target Milestone: rc
: 8.0
Assignee: Charalampos Stratakis
QA Contact: Lukáš Zachar
URL:
Whiteboard:
Depends On: 1658271 1661186 1679646
Blocks: 1684464
TreeView+ depends on / blocked
 
Reported: 2018-10-01 15:51 UTC by Adrian Reber
Modified: 2021-10-15 09:11 UTC (History)
10 users (show)

Fixed In Version: python3-3.6.8-9.el8
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2019-11-05 22:03:43 UTC
Type: Bug
Target Upstream Version:
Embargoed:

Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Red Hat Bugzilla 1543394 0 unspecified CLOSED redhat-rpm-config: Provide macros for extension builders 2021-02-22 00:41:40 UTC
Red Hat Product Errata RHSA-2019:3520 0 None None None 2019-11-05 22:03:58 UTC

Internal Links: 1543394

Description Adrian Reber 2018-10-01 15:51:52 UTC 
A common approach for HPC sites is to install additional compilers for its users. Different compiler vendors as well as different versions of gcc.

All those compilers do not include the annobin plugin. Building RPMs with those additional compilers can easily disable annobin by setting '%undefine _annotated_build', which removes annobin from RPMs optflags.

Building python modules with additional compilers does, however, not work. If installing a python module with 'python3 setup.py build' python3 somehow includes annobin usage. Not exactly sure where it takes the CFLAGS from, but grep says it could be one of those files:

/usr/lib64/python3.6/_sysconfigdata_dm_linux_x86_64-linux-gnu.py
/usr/lib64/python3.6/_sysconfigdata_m_linux_x86_64-linux-gnu.py
/usr/lib64/python3.6/config-3.6m-x86_64-linux-gnu/Makefile
/usr/libexec/platform-python3.6m-x86_64-config

All those file contain CFLAGS with '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' and it seems not possible to change these CFLAGS. Or filter these CFLAGS.

My current workaround (thanks to bz1536569) is:

export CFLAGS="-iplugindir=/usr/lib/gcc/x86_64-redhat-linux/8/plugin -fplugin=annobin -fplugin-arg-annobin-disable"

Which changes to plugin search path from my external compiler to the system compiler, then the annobin plugin is enable to disable it.

https://bugzilla.redhat.com/show_bug.cgi?id=1536569

This is rather complicated and as it changes the plugin search path of the external GCC to use plugins of the system GCC.

What would help is a way to tell python3 to return CFLAGS without annobin like it is possible inside of RPM for the optflags.
Comment 1 Petr Viktorin (pviktori) 2018-10-02 11:00:49 UTC 
How do we know which CFLAGS are for Fedora builds only, and which ones should be used when building extensions? Currently we get them all in $RPM_OPT_FLAGS.

Once that is answered the implementation should be straightforward. There is a mechanism in Python to use separate sets of flags for these.
Comment 2 Florian Weimer 2018-10-18 07:56:14 UTC 
(In reply to Petr Viktorin from comment #1)
> How do we know which CFLAGS are for Fedora builds only, and which ones
> should be used when building extensions? Currently we get them all in
> $RPM_OPT_FLAGS.
> 
> Once that is answered the implementation should be straightforward. There is
> a mechanism in Python to use separate sets of flags for these.

The problem is that extensions in Fedora must use the Fedora build flags.  So you need to add some custom logic to the extension builder to detect whether it is running under rpmbuild (maybe due to the presence of special packages or files on the system) and alter behavior.

I think it was the Ruby who did not want to do that under any circumstances, which pretty much killed this approach, and we are now adding a dependency on redhat-rpm-config and annobin to all extension builders.
Comment 3 Petr Viktorin (pviktori) 2018-10-18 08:11:49 UTC 
(In reply to Florian Weimer from comment #2)
> (In reply to Petr Viktorin from comment #1)
> > How do we know which CFLAGS are for Fedora builds only, and which ones
> > should be used when building extensions? Currently we get them all in
> > $RPM_OPT_FLAGS.
> > 
> > Once that is answered the implementation should be straightforward. There is
> > a mechanism in Python to use separate sets of flags for these.
> 
> The problem is that extensions in Fedora must use the Fedora build flags. 
> So you need to add some custom logic to the extension builder to detect
> whether it is running under rpmbuild (maybe due to the presence of special
> packages or files on the system) and alter behavior.

Is setting extra CFLAGS (and other env vars) not enough?

> I think it was the Ruby who did not want to do that under any circumstances,
> which pretty much killed this approach, and we are now adding a dependency
> on redhat-rpm-config and annobin to all extension builders.

I don't see how that means we can't have two separate sets of flags. If the union of the two sets is put in $RPM_OPT_FLAGS, Ruby can continue to use that.
But I don't want to maintain Python-specific code to separate the two sets out of $RPM_OPT_FLAGS.
Comment 4 Florian Weimer 2018-10-18 08:22:43 UTC 
(In reply to Petr Viktorin from comment #3)
> (In reply to Florian Weimer from comment #2)
> > (In reply to Petr Viktorin from comment #1)
> > > How do we know which CFLAGS are for Fedora builds only, and which ones
> > > should be used when building extensions? Currently we get them all in
> > > $RPM_OPT_FLAGS.
> > > 
> > > Once that is answered the implementation should be straightforward. There is
> > > a mechanism in Python to use separate sets of flags for these.
> > 
> > The problem is that extensions in Fedora must use the Fedora build flags. 
> > So you need to add some custom logic to the extension builder to detect
> > whether it is running under rpmbuild (maybe due to the presence of special
> > packages or files on the system) and alter behavior.
> 
> Is setting extra CFLAGS (and other env vars) not enough?

It requires writing logic in the extension builder to evaluate them.  Usually, they are not sensitive to CFLAGS at all.  Is Python different?

> > I think it was the Ruby who did not want to do that under any circumstances,
> > which pretty much killed this approach, and we are now adding a dependency
> > on redhat-rpm-config and annobin to all extension builders.
> 
> I don't see how that means we can't have two separate sets of flags. If the
> union of the two sets is put in $RPM_OPT_FLAGS, Ruby can continue to use
> that.
> But I don't want to maintain Python-specific code to separate the two sets
> out of $RPM_OPT_FLAGS.

That's reasonable.  I still may have patches somewhere which separate the flags, specifically around annobin usage.
Comment 5 Florian Weimer 2018-10-18 08:26:58 UTC 
Bug 1543394 comment 7 shows a potential patch for redhat-rpm-config.

Adrian, I think this also covers your other requirement, compiling Python extensions with non-GCC compilers which do not understand -specs=.  Right?
Comment 6 Petr Viktorin (pviktori) 2018-10-18 08:31:25 UTC 
(In reply to Florian Weimer from comment #4)
> (In reply to Petr Viktorin from comment #3)
> > (In reply to Florian Weimer from comment #2)
> > > (In reply to Petr Viktorin from comment #1)
> > > > How do we know which CFLAGS are for Fedora builds only, and which ones
> > > > should be used when building extensions? Currently we get them all in
> > > > $RPM_OPT_FLAGS.
> > > > 
> > > > Once that is answered the implementation should be straightforward. There is
> > > > a mechanism in Python to use separate sets of flags for these.
> > > 
> > > The problem is that extensions in Fedora must use the Fedora build flags. 
> > > So you need to add some custom logic to the extension builder to detect
> > > whether it is running under rpmbuild (maybe due to the presence of special
> > > packages or files on the system) and alter behavior.
> > 
> > Is setting extra CFLAGS (and other env vars) not enough?
> 
> It requires writing logic in the extension builder to evaluate them. 
> Usually, they are not sensitive to CFLAGS at all.  Is Python different?

It should be. We should fix it if it's not.
Comment 7 Petr Viktorin (pviktori) 2018-11-01 15:04:18 UTC 
Florian, how can we help move this forward?
Comment 8 Florian Weimer 2018-11-12 12:09:16 UTC 
(In reply to Petr Viktorin from comment #7)
> Florian, how can we help move this forward?

See comment 5.  I'm waiting for comments from Adrian.
Comment 9 Adrian Reber 2018-11-14 23:49:35 UTC 
I had a look at that patch, but I think I do not understand it. This seems to be for building with RPM. Which definitely fix my problem if it no longer sets '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' .

As I reported that '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' is set from one of those files:

/usr/lib64/python3.6/_sysconfigdata_dm_linux_x86_64-linux-gnu.py
/usr/lib64/python3.6/_sysconfigdata_m_linux_x86_64-linux-gnu.py
/usr/lib64/python3.6/config-3.6m-x86_64-linux-gnu/Makefile
/usr/libexec/platform-python3.6m-x86_64-config

It is not clear how changing RPM flags would help in my case.
Comment 10 Florian Weimer 2018-11-22 16:08:08 UTC 
(In reply to Adrian Reber from comment #9)
> I had a look at that patch, but I think I do not understand it. This seems
> to be for building with RPM. Which definitely fix my problem if it no longer
> sets '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' .
> 
> As I reported that '-specs=/usr/lib/rpm/redhat/redhat-annobin-cc1' is set
> from one of those files:
> 
> /usr/lib64/python3.6/_sysconfigdata_dm_linux_x86_64-linux-gnu.py
> /usr/lib64/python3.6/_sysconfigdata_m_linux_x86_64-linux-gnu.py
> /usr/lib64/python3.6/config-3.6m-x86_64-linux-gnu/Makefile
> /usr/libexec/platform-python3.6m-x86_64-config
> 
> It is not clear how changing RPM flags would help in my case.

My intent was that roughly the following would happen (using Python here as an example):

* Python would stop hard-coding the current flags from redhat-rpm-config.

* Instead, Python would store flags from redhat-rpm-config designed for building extensions with various toolchains, providing reduced hardening coverage and Fedora build flags compliance.  These would be used for building extensions using the usual Python mechanisms.

* But for distribution RPM builds, Python would still use the standard redhat-rpm-config build flags from the *current* build environment (and not the flags captured at Python build time).  This ensures hardening coverage and build flags compliance for the Python extension modules we build ourselves.

* If an end user wishes to follow our policies, they can use a mock buildroot or trigger whatever mechanism is used to switch to the distribution build behavior.

I hope this clarifies why a second set of flags is desirable in this context.
Comment 12 Adrian Reber 2018-11-23 11:23:30 UTC 
Florian, this all sounds like it would work for at least what I am looking for. Thanks for finding a solution.
Comment 13 Petr Viktorin (pviktori) 2018-11-29 12:59:19 UTC 
Is there any way for me to help move this forward?
Comment 14 Victor Stinner 2018-12-11 13:04:28 UTC 
Florian Weimer updated his redhat-rpm-config patch: https://bugzilla.redhat.com/show_bug.cgi?id=1543394#c13
Comment 15 Charalampos Stratakis 2018-12-14 00:52:39 UTC 
Experimental PR for Fedora: https://src.fedoraproject.org/rpms/python3/pull-request/75#
Comment 16 Petr Viktorin (pviktori) 2019-01-17 12:52:04 UTC 
This is now in Rawhide (Rawhide's redhat-rpm-config >= 127; note that versioning in other Fedoras may be different).

It can be ported to RHEL8.
Comment 20 Miroslav Lichvar 2019-09-30 15:33:20 UTC 
FWIW, as an expected side effect it seems this change may cause python modules packaged in RHEL to lose annobin coverage after rebuild if they don't add the rpm CFLAGS to the flags returned by python3-config --cflags.
Comment 22 errata-xmlrpc 2019-11-05 22:03:43 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, 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/RHSA-2019:3520
Note You need to log in before you can comment on or make changes to this bug.