[Rpm-maint] [rpm-software-management/rpm] Behave more consistently when target arch %optflags are not defined (PR #2622)

Panu Matilainen notifications at github.com
Mon Aug 21 11:21:26 UTC 2023


You're about to fall into a deep dark hole, proceed at your own risk.

When building for a target architecture with no defined %optflags (such as noarch), one would think that %optflags would be empty. Not so in rpm, instead we get %optflags for the detected architecture, and there are packages which rely on this behavior. And in this particular dark corner, buildarchtranslate is not applied so one can get drastically different %optflags than you'd get without an explicit --target, on the same system. Which can break builds.

None of this makes any sense whatsoever, but lets at least try to be consistent about it. When we fall back to detected architecture %optflags, at least use the ones after buildarchtranslate to return consistent data within a host.

This supposedly fixes the case where our newly added x86_64 subarchitecture definitions haven't been overridden in vendor config and somebody's noarch package uses cmake to install data, and falls over due to nonsensical optflags from rpm. Or something like that.

Initial report: https://bugzilla.redhat.com/show_bug.cgi?id=2231727
You can view, comment on, or merge this pull request online at:

  https://github.com/rpm-software-management/rpm/pull/2622

-- Commit Summary --

  * Behave more consistently when target arch %optflags are not defined

-- File Changes --

    M lib/rpmrc.c (7)

-- Patch Links --

https://github.com/rpm-software-management/rpm/pull/2622.patch
https://github.com/rpm-software-management/rpm/pull/2622.diff

-- 
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/pull/2622
You are receiving this because you are subscribed to this thread.

Message ID: <rpm-software-management/rpm/pull/2622 at github.com>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20230821/e595a095/attachment.html>


More information about the Rpm-maint mailing list