Horst von Brand wrote:
Jeremy Katz <katzj@xxxxxxxxxx> wrote:
Although I hate to do it, it looks like we're going to have to slip
Fedora Core 5 test3 by a week. There is an ABI change in the gcc/glibc
stack that requires a rebuild of the entire distribution.
May I ask what the change is, and how it affects stuff? ABI changes in C
are scary...
from a previous email:
We are changing long double type on ppc{32,64}, s390{,x}, sparc (32-bit),
and alpha. Previously long double has been the same type as double
on these architectures, now it will be either IEEE 754 quad format
long double (112 (+1 implicit) bits mantissa, 15 bits exponent, 1 bit sign;
on s390{,x}, sparc and alpha) or IBM extended format (pair of double values
with some special rules).
glibc has been changed so that it is backwards compatible with programs
and shared libraries that use 64-bit long double, but also supports the
128-bit one, even when compiling packages you can choose the long double
format (-mlong-double-64 resp. -mlong-double-128, which will be the
new default). libstdc++.so.6 is also made backwards compatible with
64-bit long double, but supporting 128-bit long double as well (and
similarly libgcc_s.so.1).
In addition to this, there are other reasons why a complete rebuild of the
entire distribution is desirable:
1) there used to be a bug on i?86 which caused incorrect .eh_frame section
being generated (terminated before end of section), which makes e.g.
valgrind complain loudly and also means .eh_frame_hdr can't be used to speed
up exception handling. This bug has been fixed a long time ago, but many
packages haven't been rebuilt since then.
2) on ia64 debug info wasn't properly describing function prologues
3) many binaries on ia64 were having text relocations, which is bad
from security POV
4) on i?86 and x86_64, -mtune=generic option has been added, which means
tuning for a pool of most commonly used CPUs. According to SPEC results
the code is no worse than -mtune={nocona,pentium4} used before on Intel
CPUs and is significantly better on AMD CPUs.
Jakub
--
fedora-devel-list mailing list
fedora-devel-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/fedora-devel-list
