I know you want FTBFS bugs now for gcc-12 issues, but let me run this by you first and I will open a BZ if necessary.
For ceph I've hacked up a fix for all the other gcc-12isms in ceph and now it fails to build on ppc64le[1] with ... /usr/bin/ld: /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2: undefined reference to `int fmt::v8::detail::format_float<__ieee128>(__ieee128, int, fmt::v8::detail::float_specs, fmt::v8::detail::buffer<char>&)' /usr/bin/ld: /builddir/build/BUILD/ceph-16.2.7/build/redhat-linux-build/lib/libceph-common.so.2: undefined reference to `int fmt::v8::detail::snprintf_float<__ieee128>(__ieee128, int, fmt::v8::detail::float_specs, fmt::v8::detail::buffer<char>&)' collect2: error: ld returned 1 exit status ... Which I presume is related to the failed rebuild of fmt[2] with gcc-12 and thus I'm still getting a version of fmt compiled with gcc-11. For which I propose to exclude ppc64le until such time as the fmt build gets fixed, when I will reënable it. [1] https://koji.fedoraproject.org/koji/taskinfo?taskID=81628812 [2] https://koji.fedoraproject.org/koji/taskinfo?taskID=81489199 On Fri, Jan 14, 2022 at 9:33 AM Jakub Jelinek <ja...@redhat.com> wrote: > Hi! > > gcc 12 snapshot has landed as the system compiler into rawhide today. > GCC 12 is going to enter its stage4 development phase (only regression > and documentation bugfixes allowed) on Monday 17th, so there should be > just those bugfixes and not new features etc. anymore. > https://gcc.gnu.org/gcc-12/changes.html lists important changes, > most important is probably that vectorization is enabled at -O2 now > which is the option with most of the distribution is built with. > > https://gcc.gnu.org/gcc-12/porting_to.html is so far incomplete and lists > some cases where people need to adjust their code. Other things > include the usual C++ header changes, where previously some standard > header included some other header as an implementation detail but it > doesn't > any longer and so code that relied on such indirect include that isn't > required by the standard needs to include the header that provides whatever > it relies on. Or e.g. packages using -Werror where new warnings are > reported with the newer compiler and -Werror results in build failures. > > If there are bugs on the compiler side, please let me know immediately, > so that those bugs can be fixed before the mass rebuild next week. > > Another important thing I wanted to say is that we'd like to switch > ppc64le from the numerically problematic IBM extended long double to > IEEE 754 quad long double. This is an ABI change. Some libraries > are already built so that they support both ABIs at the same time, > including glibc, libstdc++, libgcc, libgfortran etc. > For other libraries and binaries, the compiler, assembler and linker > will notice if they use long double and flag them as using either > IBM or IEEE long double and linker (or I think dynamic linker too) > might complain when things are mixed. > Right now the rawhide gcc still defaults to -mabi=ibmlongdouble > but the glibc/gcc libraries are built compatibly with both. > We'd like to configure gcc shortly before the mass rebuild with > --with-long-double-format=ieee so that it will default to > -mabi=ieeelongdouble, probably on a side-tag build first, and it > will be highly desirable to rebuild at least some of the most commonly > used library packages in the order of dependencies there, otherwise > I'd be afraid the mass rebuild could fail for way too many packages > (as the mass rebuild doesn't do dependency order rebuilds but just > goes through packages alphabetically or so). > Any suggestions on which packages have commonly used library packages > that use long double? > readelf -A on libraries on ppc64le prints either nothing (either > the library is thought not to use long double or supports both ABIs > transparently or hasn't been rebuilt for some years), or > Attribute Section: gnu > File Attributes > Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double > for libraries (or binaries or object files) that use IBM long double > only or > Attribute Section: gnu > File Attributes > Tag_GNU_Power_ABI_FP: hard float, 128-bit IEEE long double > for IEEE long doubles. > So I think we want to rebuild on a side-tag packages that > provide shared libraries used by hundreds of other packages that > are > Tag_GNU_Power_ABI_FP: hard float, 128-bit IBM long double > right now. > > Jakub > _______________________________________________ > devel mailing list -- devel@lists.fedoraproject.org > To unsubscribe send an email to devel-le...@lists.fedoraproject.org > Fedora Code of Conduct: > https://docs.fedoraproject.org/en-US/project/code-of-conduct/ > List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines > List Archives: > https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org > Do not reply to spam on the list, report it: > https://pagure.io/fedora-infrastructure > -- Kaleb
_______________________________________________ devel mailing list -- devel@lists.fedoraproject.org To unsubscribe send an email to devel-le...@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/devel@lists.fedoraproject.org Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
