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 <jakub@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-leave@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