To disable LTO, the recommendation is to set `%global _lto_cflags %{nil}`, which has the expected effect of removing LTO flags from `CFLAGS`. However, the extensions are still built with LTO because Python has stored those flags internally. # python3 -c 'import sysconfig; print(sysconfig.get_config_var("CFLAGS"))' -Wno-unused-result -Wsign-compare -DDYNAMIC_ANNOTATIONS_ENABLED=1 -DNDEBUG -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 -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -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 -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv -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 -fstack-protector-strong -m64 -mtune=generic -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection -D_GNU_SOURCE -fPIC -fwrapv (many times over, for some reason) Version-Release number of selected component (if applicable): python3-3.9.0~rc1-2.fc34.x86_64
That is because the lto flags are hardcoded in %{extension_cflags}: <mock-chroot> sh-5.0# rpm --eval '%{extension_cflags}' -O2 -flto=auto -ffat-lto-objects ... I believe that should not be the case and lto flags should only be in %{build_cflags}. Implementation-wise, I believe that %__extension_strip_flags should also strip %_lto_cflags. Jeff, do you agree? If so, I'll prepare a PR.
The lto flags are controlled via: %_gcc_lto_cflags -flto=auto -ffat-lto-objects %_clang_lto_cflags -flto %_lto_cflags %{expand:%%{_%{toolchain}_lto_cflags}} %_general_options -O2 %{?_lto_cflags} -fexceptions -g -grecord-gcc-switches -pipe %__global_compiler_flags %{_general_options} %{_warning_options} %{_preprocessor_defines} %{_hardened_cflags} %{_annotation_cflags} %{_legacy_options} Which then feed into optflags and build_cflags. And I think that is doing exactly what we want. So the question I would ask is how is extension_cflags set. And the answer is: %extension_cflags %{__extension_strip_flags cflags} I would hazard a guess that the problem is python stuffed away the flags it built with and those are being used in extension builds -- which would (to the best of my knowledge) happen behind the back of rpm. And I think that's what extension_strip_flags is supposed to handle -- verifying that chain assumptions seems wise. If that is indeed what's happening, then filtering out the lto flags when lto_cflags is %{nil} inside extension_strip_flags seems like the best choice. That way the default remains to build with LTO and the standard opt-out mechanism works as expected.
(In reply to Jeff Law from comment #2) > I would hazard a guess that the problem is python stuffed away the flags it > built with and those are being used in extension builds -- which would (to > the best of my knowledge) happen behind the back of rpm. And I think that's > what extension_strip_flags is supposed to handle -- verifying that chain > assumptions seems wise. If that is indeed what's happening, then filtering > out the lto flags when lto_cflags is %{nil} inside extension_strip_flags > seems like the best choice. That way the default remains to build with LTO > and the standard opt-out mechanism works as expected. I would expect that you would have to filter out the LTO flags *unconditionally*, so that they do not get baked into extension builders like Python. I should have thought of that when you posted your LTO changes. 8-/
> I would hazard a guess that the problem is python stuffed away the flags it built with and those are being used in extension builds... Python stuffs away the flags it was told to stuff. We tell it to stuff away %extension_cflags. This is what %extension_cflags is documented for. > filtering out the lto flags when lto_cflags is %{nil} inside extension_strip_flags seems like the best choice. I ask to filter the lto flags from %extension_cflags unconditionally. Filtering them out when %lto_cflags is %{nil} makes no difference, because in that case, they are not there to be filter out.
Thanks for fixing my misunderstanding of what extension_cflags is supposed to do. So given my updated understanding, the question becomes do we want extensions to use LTO. A part of my says, "of course", but then I'm not aware of how a package would opt-out which argues that we shouldn't leak the LTO options into the extensions flags. So perhaps in the immediate term we strip the lto flags out of extension_cflags unconditionally.
Note that this affects not only other RPM packages that build extension modules, but also users who build their own. I'll send a PR.
Ready for review in https://src.fedoraproject.org/rpms/redhat-rpm-config/pull-request/106
FEDORA-2020-5266fbbe2b has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-ef7402b558 has been pushed to the Fedora ELN stable repository. If problem still persists, please make note of it in this bug report.
Pythons need to be rebuilt with the new macros.
FEDORA-2020-8f15d4d72f has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-8f15d4d72f
FEDORA-2020-78bb031321 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-78bb031321
The following Fedora packages utilize %extension_c(xx)flags: - python3.9: https://bodhi.fedoraproject.org/updates/FEDORA-2020-78bb031321 - python3.8: to be rebuilt when Python 3.8.6 final is released - python3.7: no planed release soon, will bump and build some time before Fedora 33 final freeze - python3.6: no planed release soon, will bump and build some time before Fedora 33 final freeze
FEDORA-2020-8f15d4d72f has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-8f15d4d72f` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-8f15d4d72f See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-78bb031321 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-78bb031321` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-78bb031321 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-0c4b4837e5 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-32f938e002 has been pushed to the Fedora 34 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-4a32301609 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-4a32301609
- python3.9: https://bodhi.fedoraproject.org/updates/FEDORA-2020-78bb031321 - python3.8: to be rebuilt when Python 3.8.6 final is released - python3.7: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4a32301609 - python3.6: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4a32301609
FEDORA-2020-4a32301609 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-4a32301609` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-4a32301609 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-060f42bc47 has been submitted as an update to Fedora 33. https://bodhi.fedoraproject.org/updates/FEDORA-2020-060f42bc47
FEDORA-2020-8f15d4d72f has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-060f42bc47 has been pushed to the Fedora 33 testing repository. In short time you'll be able to install the update with the following command: `sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2020-060f42bc47` You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2020-060f42bc47 See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.
FEDORA-2020-78bb031321 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-4a32301609 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.
FEDORA-2020-060f42bc47 has been pushed to the Fedora 33 stable repository. If problem still persists, please make note of it in this bug report.