Fedora Core 5 Test 3 Slip

[Richard Hally]

Horst von Brand wrote:
> Jeremy Katz <katzj at redhat.com> 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