When doing builds for EPEL9 some builds were failing because of missing CXXFLAGS, I was able to solve this by using %set_build_flags as advised by churchyard. Reproducible: Always Steps to Reproduce: 1. fedpkg co python-Levenshtein 2. fedpkg --release epel9 srpm --define "dist .el9.infra" 3. koji build --scratch epel9-infra python-Levenshtein-0.23.0-3.el9.src.rpm Actual Results: The build fails because of missing CXXFLAGS Expected Results: The build is successful
So, the %pyproject_wheel and %pyproject_buildrequires macros currently only set: CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}" This has been copied from %py3_build. With distutils/setuptools, I assume CFLAGS were used even for C++, co this was likely never a problem. With the spawn of new build backends, this might become a problem. In Fedora, it's likely moot because _auto_set_build_flags is the default, but as said, this affects EL 9. The macros that we might need to care about are: %set_build_flags \ CFLAGS="${CFLAGS:-%{build_cflags}}" ; export CFLAGS ; \ CXXFLAGS="${CXXFLAGS:-%{build_cxxflags}}" ; export CXXFLAGS ; \ FFLAGS="${FFLAGS:-%{build_fflags}}" ; export FFLAGS ; \ FCFLAGS="${FCFLAGS:-%{build_fflags}}" ; export FCFLAGS ; \ VALAFLAGS="${VALAFLAGS:-%{build_valaflags}}" ; export VALAFLAGS ;%{?build_rustflags: RUSTFLAGS="${RUSTFLAGS:-%{build_rustflags}}" ; export RUSTFLAGS ;} \ LDFLAGS="${LDFLAGS:-%{build_ldflags}}" ; export LDFLAGS ; \ LT_SYS_LIBRARY_PATH="${LT_SYS_LIBRARY_PATH:-%_libdir:}" ; export LT_SYS_LIBRARY_PATH ; \ CC="${CC:-%{__cc}}" ; export CC ; \ CXX="${CXX:-%{__cxx}}" ; export CXX Ideally, we would call all this without the exports. A clever string manipulation might make that possible. Nevertheless, a short-term fix might be to have: CFLAGS="${CFLAGS:-%{build_cflags}}" CXXFLAGS="${CFLAGS:-%{build_cxxflags}}" LDFLAGS="${LDFLAGS:-%{build_ldflags}}"
Lua: local set_build_flags = macros.set_build_flags .. ';' set_build_flags:gsub(";+%s+export%s+%u+%s*;+", "\\") This seems to work.
Part 1: https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/307
You can use this instead (we can assume bash): declare +x CFLAGS CXXFLAGS LDFLAGS I don't understand the nature of this bug. Why does shell variable export matter here?
The nature of this bug is: Premise: We are in an environment where _auto_set_build_flags is disabled. That could be either EL9 or Fedora with %undefine _auto_set_build_flags. Expectations: The %pyproject_wheel macro sets the relevant flags when building Python extension modules. Status quo: The %pyproject_wheel macro sets CFLAGS and LDFLAGS only as this was historically good enough. Problem: There are other flags (such as CXXFLAGS described in this bug, but it could be for example RUSTFLAGS as well) that need to be set. Solution: Set all the flags as defined in %set_build_flags within %pyproject_wheel. Problem with %set_build_flags as it currently is defined: It exports the environment variables, thus "leaking" them beyond %pyproject_wheel. Solution: Take all the flags as set via %set_build_flags but do not export them. This is solvable by string manipulation, but I don't want to keep that internal to %pyproject_wheel, hence https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/307 -- when that macro exists, I'd do: %pyproject_wheel(C:) %{expand:\\\ %_set_pytest_addopts mkdir -p "%{_pyproject_builddir}" -CFLAGS="${CFLAGS:-${RPM_OPT_FLAGS}}" LDFLAGS="${LDFLAGS:-${RPM_LD_FLAGS}}" TMPDIR="%{_pyproject_builddir}" \\\ +%{build_flags} TMPDIR="%{_pyproject_builddir}" \\\ %{__python3} -Bs %{_rpmconfigdir}/redhat/pyproject_wheel.py %{?**} %{_pyproject_wheeldir} }
Even if not exported, the variable setting still leaks outside this context, to other parts of the %build section afterwards. Maybe you could try this instead: %pyproject_wheel(C:) %{expand:\\\ %_set_pytest_addopts mkdir -p "%{_pyproject_builddir}" ( %set_build_flags %{__python3} -Bs %{_rpmconfigdir}/redhat/pyproject_wheel.py %{?**} %{_pyproject_wheeldir} ) } The ( … ) introduce a subshell, so the values revert to their previous (typically unset, unexpected) status afterwards.
> Even if not exported, the variable setting still leaks outside this context, How? Note that the line would be: CFLAGS=... CXXFLAGS=... TMPDIR=... /usr/bin/python3 ...pyproject_wheel.py I am aware of the subshell trick, but I was afraid of what that would do with specfiles that append something to the macro call like this `%{pyproject_wheel} --hehe`.
(In reply to Miro Hrončok from comment #7) > > Even if not exported, the variable setting still leaks outside this context, > > How? Note that the line would be: > > CFLAGS=... CXXFLAGS=... TMPDIR=... /usr/bin/python3 ...pyproject_wheel.py Ahh, so what you want is something that fits on a single line, without intervening shell commands. This is a bit different from dropping the export statements. Implementation-wise, I think it would make sense to layer %set_build_flags on top of the new macro, just adding the export directives, avoiding the sed hacks.
> Implementation-wise, I think it would make sense to layer %set_build_flags on top of the new macro, just adding the export directives, avoiding the sed hacks. Possibly right, but I did not want to break anything. Adding a new macro is an easily backportable change.
https://src.fedoraproject.org/rpms/pyproject-rpm-macros/pull-request/476
FEDORA-2024-c1ee568637 (pyproject-rpm-macros-1.15.0-1.fc42) has been submitted as an update to Fedora 42. https://bodhi.fedoraproject.org/updates/FEDORA-2024-c1ee568637
FEDORA-2024-c1ee568637 (pyproject-rpm-macros-1.15.0-1.fc42) has been pushed to the Fedora 42 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-f17e2f559b (pyproject-rpm-macros-1.15.0-1.fc40) has been submitted as an update to Fedora 40. https://bodhi.fedoraproject.org/updates/FEDORA-2024-f17e2f559b
FEDORA-2024-aa49f791e5 (pyproject-rpm-macros-1.15.0-1.fc41) has been submitted as an update to Fedora 41. https://bodhi.fedoraproject.org/updates/FEDORA-2024-aa49f791e5
FEDORA-2024-97e69afef1 (pyproject-rpm-macros-1.15.0-1.fc39) has been submitted as an update to Fedora 39. https://bodhi.fedoraproject.org/updates/FEDORA-2024-97e69afef1
FEDORA-2024-97e69afef1 has been pushed to the Fedora 39 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-97e69afef1` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-97e69afef1 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-f17e2f559b has been pushed to the Fedora 40 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-f17e2f559b` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-f17e2f559b See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-aa49f791e5 has been pushed to the Fedora 41 testing repository. Soon you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --refresh --advisory=FEDORA-2024-aa49f791e5` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2024-aa49f791e5 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2024-aa49f791e5 (pyproject-rpm-macros-1.15.0-1.fc41) has been pushed to the Fedora 41 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-f17e2f559b (pyproject-rpm-macros-1.15.0-1.fc40) has been pushed to the Fedora 40 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2024-97e69afef1 (pyproject-rpm-macros-1.15.1-1.fc39) has been pushed to the Fedora 39 stable repository. If problem still persists, please make note of it in this bug report.
This is now on its way to c9s in pyproject-rpm-macros-1.16.2-1.el9.