Hi Trying to build the new Chromium version 103.0.5060.134 for MGA8, I got an error I suspected to be related to libstdc++-devel So, I tried to rebuild the current version 103.0.5060.53 which has been successful when using the previous gcc-10.3.0-2; the build failed in the same way when using the current gcc-10.4.0-2 The error I get is: In file included from ../../third_party/vulkan-deps/vulkan-validation-layers/src/layers/core_validation.cpp:59: /usr/lib/gcc/x86_64-mageia-linux-gnu/10/../../../../include/c++/10/valarray:1214:5: error: exception specification in declaration does not match previous declaration begin(valarray<_Tp>& __va) noexcept ^ /usr/lib/gcc/x86_64-mageia-linux-gnu/10/../../../../include/c++/10/bits/range_access.h:107:31: note: previous declaration is here template<typename _Tp> _Tp* begin(valarray<_Tp>&); ^ In file included from ../../third_party/vulkan-deps/vulkan-validation-layers/src/layers/core_validation.cpp:59: /usr/lib/gcc/x86_64-mageia-linux-gnu/10/../../../../include/c++/10/valarray:1224:5: error: exception specification in declaration does not match previous declaration begin(const valarray<_Tp>& __va) noexcept ^ /usr/lib/gcc/x86_64-mageia-linux-gnu/10/../../../../include/c++/10/bits/range_access.h:108:37: note: previous declaration is here template<typename _Tp> const _Tp* begin(const valarray<_Tp>&); ^ In file included from ../../third_party/vulkan-deps/vulkan-validation-layers/src/layers/core_validation.cpp:59: /usr/lib/gcc/x86_64-mageia-linux-gnu/10/../../../../include/c++/10/valarray:1234:5: error: exception specification in declaration does not match previous declaration end(valarray<_Tp>& __va) noexcept ^ /usr/lib/gcc/x86_64-mageia-linux-gnu/10/../../../../include/c++/10/bits/range_access.h:109:31: note: previous declaration is here template<typename _Tp> _Tp* end(valarray<_Tp>&); ^ In file included from ../../third_party/vulkan-deps/vulkan-validation-layers/src/layers/core_validation.cpp:59: /usr/lib/gcc/x86_64-mageia-linux-gnu/10/../../../../include/c++/10/valarray:1249:5: error: exception specification in declaration does not match previous declaration end(const valarray<_Tp>& __va) noexcept ^ /usr/lib/gcc/x86_64-mageia-linux-gnu/10/../../../../include/c++/10/bits/range_access.h:110:37: note: previous declaration is here template<typename _Tp> const _Tp* end(const valarray<_Tp>&); ^ 4 errors generated. It looks like there is something inconsistent between /usr/include/c++/10/bits/range_access.h and /usr/include/c++/10/valarray How to replicate? Rebuild chromium-browser-stable-103.0.5060.53.mga8 with gcc-10.4.0
Priority: Normal => High
CC: (none) => tmb
> I tried to rebuild the current version 103.0.5060.53 > [of chromium-browser-stable] which has been successful when using the > previous gcc-10.3.0-2; the build failed in the same way when using > the current gcc-10.4.0-2 I think it worth getting the view of cjw also, since he must have, or will be, treading the same path as maintainer of chromium-browser. Not that the problem should relate just to that particular application.
CC: (none) => cjw, lewyssmith
Assignee: bugsquad => tmb
We can compare with cauldron: /usr/include/c++/12/valarray:1215 /usr/include/c++/12/bits/range_access.h:113 Both are declared noexcept. In mga8, the 4 declarations in bits/range_access.h do not have the noexcept specifier, so the question is: were these forgotten or was noexcept mistakenly added in <valarray> while it is apparently not required in C++11 and C++14?
caused by fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103022
Blocks: (none) => 30655
(In reply to Christiaan Welvaart from comment #3) > caused by fix for https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103022 Thanks for your analysis. Should I report a bug to gcc ?
No need, I've added the upstream fix and can ping Jonathan when confirmed it works a new gcc will be submitted soon-ish
(In reply to Thomas Backlund from comment #5) > No need, I've added the upstream fix and can ping Jonathan when confirmed it > works > > a new gcc will be submitted soon-ish You rock! Thanks!
packages for test: SRPM: gcc-10.4.0-3.mga8.src.rpm i586: gcc-10.4.0-3.mga8.i586.rpm gcc-c++-10.4.0-3.mga8.i586.rpm gcc-cpp-10.4.0-3.mga8.i586.rpm gcc-doc-10.4.0-3.mga8.noarch.rpm gcc-gdc-10.4.0-3.mga8.i586.rpm gcc-gfortran-10.4.0-3.mga8.i586.rpm gcc-gnat-10.4.0-3.mga8.i586.rpm gcc-objc++-10.4.0-3.mga8.i586.rpm gcc-objc-10.4.0-3.mga8.i586.rpm gcc-plugins-10.4.0-3.mga8.i586.rpm libasan6-10.4.0-3.mga8.i586.rpm libasan-devel-10.4.0-3.mga8.i586.rpm libatomic1-10.4.0-3.mga8.i586.rpm libatomic-devel-10.4.0-3.mga8.i586.rpm libgcc1-10.4.0-3.mga8.i586.rpm libgfortran5-10.4.0-3.mga8.i586.rpm libgnat10-10.4.0-3.mga8.i586.rpm libgomp1-10.4.0-3.mga8.i586.rpm libgomp-devel-10.4.0-3.mga8.i586.rpm libgphobos1-10.4.0-3.mga8.i586.rpm libitm1-10.4.0-3.mga8.i586.rpm libitm-devel-10.4.0-3.mga8.i586.rpm libobjc4-10.4.0-3.mga8.i586.rpm libquadmath0-10.4.0-3.mga8.i586.rpm libquadmath-devel-10.4.0-3.mga8.i586.rpm libstdc++6-10.4.0-3.mga8.i586.rpm libstdc++-devel-10.4.0-3.mga8.i586.rpm libstdc++-docs-10.4.0-3.mga8.noarch.rpm libstdc++-python-devel-10.4.0-3.mga8.i586.rpm libstdc++-static-devel-10.4.0-3.mga8.i586.rpm libubsan1-10.4.0-3.mga8.i586.rpm libubsan-devel-10.4.0-3.mga8.i586.rpm x86_64: gcc-10.4.0-3.mga8.x86_64.rpm gcc-c++-10.4.0-3.mga8.x86_64.rpm gcc-cpp-10.4.0-3.mga8.x86_64.rpm gcc-doc-10.4.0-3.mga8.noarch.rpm gcc-gdc-10.4.0-3.mga8.x86_64.rpm gcc-gfortran-10.4.0-3.mga8.x86_64.rpm gcc-gnat-10.4.0-3.mga8.x86_64.rpm gcc-objc++-10.4.0-3.mga8.x86_64.rpm gcc-objc-10.4.0-3.mga8.x86_64.rpm gcc-plugins-10.4.0-3.mga8.x86_64.rpm libasan6-10.4.0-3.mga8.x86_64.rpm libasan-devel-10.4.0-3.mga8.x86_64.rpm libatomic1-10.4.0-3.mga8.x86_64.rpm libatomic-devel-10.4.0-3.mga8.x86_64.rpm libgcc1-10.4.0-3.mga8.x86_64.rpm libgfortran5-10.4.0-3.mga8.x86_64.rpm libgnat10-10.4.0-3.mga8.x86_64.rpm libgomp1-10.4.0-3.mga8.x86_64.rpm libgomp-devel-10.4.0-3.mga8.x86_64.rpm libgphobos1-10.4.0-3.mga8.x86_64.rpm libitm1-10.4.0-3.mga8.x86_64.rpm libitm-devel-10.4.0-3.mga8.x86_64.rpm liblsan0-10.4.0-3.mga8.x86_64.rpm liblsan-devel-10.4.0-3.mga8.x86_64.rpm libobjc4-10.4.0-3.mga8.x86_64.rpm libquadmath0-10.4.0-3.mga8.x86_64.rpm libquadmath-devel-10.4.0-3.mga8.x86_64.rpm libstdc++6-10.4.0-3.mga8.x86_64.rpm libstdc++-devel-10.4.0-3.mga8.x86_64.rpm libstdc++-docs-10.4.0-3.mga8.noarch.rpm libstdc++-python-devel-10.4.0-3.mga8.x86_64.rpm libstdc++-static-devel-10.4.0-3.mga8.x86_64.rpm libtsan0-10.4.0-3.mga8.x86_64.rpm libtsan-devel-10.4.0-3.mga8.x86_64.rpm libubsan1-10.4.0-3.mga8.x86_64.rpm libubsan-devel-10.4.0-3.mga8.x86_64.rpm
Hi Should rpm-build be updated as well? I use mock for packaging, and it looks like rpm-build installation happens first; installing gcc-10.4.0-2 from core/updates and preventing to update from core/updates_testing afterwards. The core/updates_testing repo is considered by Mock later on, as some buildrequires come from there after chroot env is set up.
(In reply to christian barranco from comment #8) > Hi > Should rpm-build be updated as well? Nope. > I use mock for packaging, and it looks like rpm-build installation happens > first; installing gcc-10.4.0-2 from core/updates and preventing to update > from core/updates_testing afterwards. > The core/updates_testing repo is considered by Mock later on, as some > buildrequires come from there after chroot env is set up. I guess you need to add "Core Updates Testing" as a medium for mock to use
(In reply to Thomas Backlund from comment #9) > (In reply to christian barranco from comment #8) > > Hi > > Should rpm-build be updated as well? > > Nope. > > > I use mock for packaging, and it looks like rpm-build installation happens > > first; installing gcc-10.4.0-2 from core/updates and preventing to update > > from core/updates_testing afterwards. > > The core/updates_testing repo is considered by Mock later on, as some > > buildrequires come from there after chroot env is set up. > > I guess you need to add "Core Updates Testing" as a medium for mock to use I have already added the Testing repo. It works for other libs, but not for gcc. gcc is installed during the chroot setup by rpm-build, and it is not updated after wards.
(In reply to christian barranco from comment #10) > > I have already added the Testing repo. It works for other libs, but not for > gcc. > gcc is installed during the chroot setup by rpm-build, and it is not updated > after wards. So force it with: BuildRequires: gcc >= 10.4.0-3
Thanks to Christiaan & Thomas for rapid reactions.
CC: lewyssmith => (none)
Hi. Thanks to this 10.4.0-3 I was able to package Chromium locally last night. Bug fixed! Thanks
Hi. Should I move it as Ready for QA?
rpms list in comment 7, confirmed fix for the regression in comment 13... other than that a few fortran fixes and a d one... Advisory, added to svn: type: bugfix subject: Updated gcc packages fixes a few bugs and a regression src: 8: core: - gcc-10.4.0-3.mga8 description: | The update to gcc 10.4 in MGAA-2022-0094 caused a regression in valarray definition causing atleast chromiom builds to fail. This update fixes that regression, and also adds the following fixes: - d: Fix error: aggregate value used where floating point was expected - Fortran: improve error recovery for EXTENDS_TYPE_OF() [PR106121] - Fortran: error recovery on invalid CLASS(), PARAMETER declarations [PR105243] - Fortran: do not generate conflicting results under -ff2c [PR104313] - tree-sra: Fix union handling in build_reconstructed_reference references: - https://bugs.mageia.org/show_bug.cgi?id=30658
Assignee: tmb => qa-bugsKeywords: (none) => advisory
Hi. What does remain to be done to move it to Updates ? I need it to update Chromium for Mageia 8.
(In reply to christian barranco from comment #16) > Hi. What does remain to be done to move it to Updates ? > I need it to update Chromium for Mageia 8. Just submit Chromium to updates_testing with the same: BuildRequires: gcc >= 10.4.0-3 and it will ensure it will be used during the build
Whiteboard: (none) => MGA8-64-OK, MGA8-32-OKKeywords: (none) => validated_updateCC: (none) => sysadmin-bugs
An update for this issue has been pushed to the Mageia Updates repository. https://advisories.mageia.org/MGAA-2022-0103.html
Resolution: (none) => FIXEDStatus: NEW => RESOLVED