Many Pythons started to fail in Fedora on x86_64 and aarch64 with:
+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: no symbols /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: no symbols
+ /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: no symbols /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: no symbols
Right before the mass rebuild. Is this known?
https://koschei.fedoraproject.org/affected-by/redhat-rpm-config?epoch1=0&... https://koschei.fedoraproject.org/affected-by/gcc-c++?epoch1=0&version1=...
On 20/01/21 11:31 +0100, Miro Hrončok wrote:
Many Pythons started to fail in Fedora on x86_64 and aarch64 with:
- /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: no symbols /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: no symbols
- /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: no symbols /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: no symbols
Right before the mass rebuild. Is this known?
It seems to affect Boost builds too.
On 20. 01. 21 11:31, Miro Hrončok wrote:
Many Pythons started to fail in Fedora on x86_64 and aarch64 with:
- /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9d-x86_64-linux-gnu/st5slPIv: no symbols /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.x86_64/usr/lib64/python3.9/config-3.9-x86_64-linux-gnu/stgbbuCz: no symbols
- /usr/lib/rpm/redhat/brp-strip-lto /usr/bin/strip
/usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9d-aarch64-linux-gnu/stOvyE1u: no symbols /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: symbol `.gnu.debuglto_.debug_line_str' required but not present /usr/bin/strip: /builddir/build/BUILDROOT/python3.9-3.9.1-1.fc34.aarch64/usr/lib64/python3.9/config-3.9-aarch64-linux-gnu/st2BV5jT: no symbols
Right before the mass rebuild. Is this known?
https://koschei.fedoraproject.org/affected-by/redhat-rpm-config?epoch1=0&...
https://koschei.fedoraproject.org/affected-by/gcc-c++?epoch1=0&version1=...
On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
On 20.01.2021 11:31, Miro Hrončok wrote:
Right before the mass rebuild. Is this known?
Fedora 34 will be built again with broken, full of regressions GCC compiler (just like Fedora 32).
Fix for this is already approved upstream and likely going into a new spin of gcc.
FWIW, it's related to flipping to dwarf5. It doesn't affect code generation.
Jeff
On 1/20/21 9:08 AM, Vitaly Zaitsev via devel wrote:
On 20.01.2021 17:03, Jeff Law wrote:
Fix for this is already approved upstream and likely going into a new spin of gcc.
Today I got two new GCC regressions in the same package. Reported to RHBZ.
THen it's a safe bet we'll fix them.
Jeff
On 20. 01. 21 17:03, Jeff Law wrote:
On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
On 20.01.2021 11:31, Miro Hrončok wrote:
Right before the mass rebuild. Is this known?
Fedora 34 will be built again with broken, full of regressions GCC compiler (just like Fedora 32).
Fix for this is already approved upstream and likely going into a new spin of gcc.
FWIW, it's related to flipping to dwarf5. It doesn't affect code generation.
Can we please check the impact of such changes in the future *before* shipping them?
On 1/20/21 9:17 AM, Miro Hrončok wrote:
On 20. 01. 21 17:03, Jeff Law wrote:
On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
On 20.01.2021 11:31, Miro Hrončok wrote:
Right before the mass rebuild. Is this known?
Fedora 34 will be built again with broken, full of regressions GCC compiler (just like Fedora 32).
Fix for this is already approved upstream and likely going into a new spin of gcc.
FWIW, it's related to flipping to dwarf5. It doesn't affect code generation.
Can we please check the impact of such changes in the future *before* shipping them?
Generally we do. If you were to look at the hundreds of fixes we've already made in F33 and F34, those are a direct result of doing our own test builds and fixing things we've found, either in the package or in gcc itself.
THe dwarf5 change went in very late upstream and thus wasn't subject to the continuous testing and fixing we've done. Sorry for that.
Jeff
On 20. 01. 21 17:21, Jeff Law wrote:
On 1/20/21 9:17 AM, Miro Hrončok wrote:
On 20. 01. 21 17:03, Jeff Law wrote:
On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
On 20.01.2021 11:31, Miro Hrončok wrote:
Right before the mass rebuild. Is this known?
Fedora 34 will be built again with broken, full of regressions GCC compiler (just like Fedora 32).
Fix for this is already approved upstream and likely going into a new spin of gcc.
FWIW, it's related to flipping to dwarf5. It doesn't affect code generation.
Can we please check the impact of such changes in the future *before* shipping them?
Generally we do. If you were to look at the hundreds of fixes we've already made in F33 and F34, those are a direct result of doing our own test builds and fixing things we've found, either in the package or in gcc itself.
Thanks!
THe dwarf5 change went in very late upstream and thus wasn't subject to the continuous testing and fixing we've done. Sorry for that.
I understand that stuff can break unexpectedly.
On 1/20/21 9:29 AM, Miro Hrončok wrote:
On 20. 01. 21 17:21, Jeff Law wrote:
On 1/20/21 9:17 AM, Miro Hrončok wrote:
On 20. 01. 21 17:03, Jeff Law wrote:
On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
On 20.01.2021 11:31, Miro Hrončok wrote:
Right before the mass rebuild. Is this known?
Fedora 34 will be built again with broken, full of regressions GCC compiler (just like Fedora 32).
Fix for this is already approved upstream and likely going into a new spin of gcc.
FWIW, it's related to flipping to dwarf5. It doesn't affect code generation.
Can we please check the impact of such changes in the future *before* shipping them?
Generally we do. If you were to look at the hundreds of fixes we've already made in F33 and F34, those are a direct result of doing our own test builds and fixing things we've found, either in the package or in gcc itself.
Thanks!
NP. It's good for Fedora and good for GCC as well.
THe dwarf5 change went in very late upstream and thus wasn't subject to the continuous testing and fixing we've done. Sorry for that.
I understand that stuff can break unexpectedly.
Yea, the timing was awful. It didn't help that when I saw this yesterday in the tester I passed it along to Nick thinking it was actually a binutils problem. So we lost a fair amount of time because of that.
jeff
On 20. 01. 21 17:03, Jeff Law wrote:
On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
On 20.01.2021 11:31, Miro Hrončok wrote:
Right before the mass rebuild. Is this known?
Fedora 34 will be built again with broken, full of regressions GCC compiler (just like Fedora 32).
Fix for this is already approved upstream and likely going into a new spin of gcc.
FWIW, it's related to flipping to dwarf5. It doesn't affect code generation.
Appears to be fixed in gcc-...-16.fc34.
https://koji.fedoraproject.org/koji/taskinfo?taskID=60148197
On 1/21/21 8:26 AM, Miro Hrončok wrote:
On 20. 01. 21 17:03, Jeff Law wrote:
On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
On 20.01.2021 11:31, Miro Hrončok wrote:
Right before the mass rebuild. Is this known?
Fedora 34 will be built again with broken, full of regressions GCC compiler (just like Fedora 32).
Fix for this is already approved upstream and likely going into a new spin of gcc.
FWIW, it's related to flipping to dwarf5. It doesn't affect code generation.
Appears to be fixed in gcc-...-16.fc34.
https://koji.fedoraproject.org/koji/taskinfo?taskID=60148197
Yes. We've been waiting for that to land. The arm32 builder croaked yesterday and it had to get restarted in the mid/late afternoon US time. I wouldn't expect it to land until mid/late afternoon today.
jeff
On Thu, Jan 21, 2021 at 08:31:31AM -0700, Jeff Law wrote:
On 1/21/21 8:26 AM, Miro Hrončok wrote:
On 20. 01. 21 17:03, Jeff Law wrote:
On 1/20/21 8:47 AM, Vitaly Zaitsev via devel wrote:
On 20.01.2021 11:31, Miro Hrončok wrote:
Right before the mass rebuild. Is this known?
Fedora 34 will be built again with broken, full of regressions GCC compiler (just like Fedora 32).
Fix for this is already approved upstream and likely going into a new spin of gcc.
FWIW, it's related to flipping to dwarf5. It doesn't affect code generation.
Appears to be fixed in gcc-...-16.fc34.
https://koji.fedoraproject.org/koji/taskinfo?taskID=60148197
Yes. We've been waiting for that to land. The arm32 builder croaked yesterday and it had to get restarted in the mid/late afternoon US time. I wouldn't expect it to land until mid/late afternoon today.
Both gcc -0.16.fc34 and fixed dwz are now in f34-build.
Jakub
Miro Hrončok wrote:
symbol `.gnu.debuglto_.debug_line_str' required but not present
This is causing a whole chain of breakage in Rawhide: The above bug prevents building binutils, which prevents fixing: https://bugzilla.redhat.com/show_bug.cgi?id=1916925 which in turn prevents rebuilding qt5-qtwebengine with my attempt to fix: https://bugzilla.redhat.com/show_bug.cgi?id=1904652 (which is actually caused by a glibc change, but I'm trying to get the Chromium/QtWebEngine sandbox to work with the changed glibc).
In addition, the .gnu.debuglto_.debug_line_str issue also breaks building qt3 according to Koschei (but I am not in a hurry to rebuild that one right now).
Kevin Kofler