As I understand it, the --with-long-double-format=ieee change should
stop Boost.Math from exploding with a preprocessor error “Sorry, but
this platform does not have sufficient long double support for the
special functions to be reliably implemented” on ppc64le[1].
This will likely allow “ExcludeArch: ppc64le” to be removed from
python-graph-tool[1].
Other packages that have both “ExcludeArch: ppc64le” and “BuildRequires:
boost*-devel” are:
* bear-factory
* digikam
* dlib
* espresso
* gource
* supertux
* synfig
* trojita
* wesnoth
If some or all of those suffer from the same problem, it might be
possible to start building them on ppc64le after the change.
Also, libcamera manually adds -mabi=ieeelongdouble to its
CFLAGS/CXXFLAGS on ppc64le, and this could be removed after the change.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1771031#c7
[2] https://bugzilla.redhat.com/show_bug.cgi?id=1771031
On 1/14/22 09:31, Jakub Jelinek 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@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
_______________________________________________
devel mailing list -- devel@xxxxxxxxxxxxxxxxxxxxxxx
To unsubscribe send an email to devel-leave@xxxxxxxxxxxxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxxxxxxx
Do not reply to spam on the list, report it: https://pagure.io/fedora-infrastructure
