Bug#156662: gcc 3.2 will need Depends and Build-Depends on binutils and glibc versions for ppc
Matthias,
Well actually it will effect builds as soon as glibc 2.2.5-14
goes in with the correct sysdeps/powerpc/libgcc-compat.S code
(which hopefully Franz will push today into glibc-2-2-branch).
The current glibc 2.2.5-13, built under gcc 2.95.4, in libc.so.6
doesn't have a dynamic symbol for __divdi3. So building gcc 3.2
with gcc 2.95.4 against that presents no problem. However once glibc
2.2.5-14 is installed, with the corrected sysdeps/powerpc/
libgcc-compat.s code, there will definitely be a Build-Depends on
binutils >= 2.13.90.0.4. The libc.so.6, built from the new
libgcc-compat.S code, will have a dynamic symbol for __divdi3
(available for run-time resolution but NOT exported for
linking). If you try to build gcc 3.2 with a binutils
earlier than 2.13.90.0.4 against such a libc.so.6, you will
end up with a flawed libgcc_s.so.1 with an unversioned __divdi3
symbol (which, if you look, is not the case with the current
gcc 3.2 builds off of voltaire). With the new binutils
2.13.90.0.4 release or later the __divdi3 will be correctly
versioned in libgcc_s.so.1 as GLIBC_2.0.
So there definitely is at least a Build-Depends for
binutils (>= 2.13.90.0.4) required for gcc 3.2 on ppc.
Granted it isn't required today, but it will be the moment
glibc 2.2.5-14 is installed. Note that this issue is
exactly what Franz Sirl's rejected versioning fixup patch
was all about...
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00252.html
Franz just didn't realize that the problem he was observing
,in building a proper libgcc_s.so.1 against his new corrected
libgcc-compat.S code was due to a binutils bug. No changes
in gcc 3.2 were required to fix it.
Jack
ps So gcc-3.2 needs a Build-Depends for binutils (>= 2.13.90.0.4)
on ppc. While glibc 2.2.5-14 doesn't need a Build-Depends, it
definitely will need a Depends on binutils (>= 2.13.90.0.4). This
is because once you install a libc.so.6 with the new libgcc-compat.S
code (that presents __divdi3 for run-time resolution but not
exported for linking), you will tickle a binutils bug in
2.13.90.0.3 or earlier. This bug causes a bogus symbol conflict
on the __divdi3 from libc.so.6...
http://sources.redhat.com/ml/binutils/2002-08/msg00173.html
http://sources.redhat.com/ml/binutils/2002-08/msg00175.html
when attempting to build things against that glibc with gcc 2.95.4
Yes, this is all pretty nasty stuff which is why it was so
hard to pinpoint and fix.
In any case, I think we minimally need two changes...
1) gcc-3.2 Build-Depends on binutils (>= 2.13.90.0.4) on ppc
2) glibc 2.2.5-14 Depends on binutils (>= 2.13.90.0.4) on ppc
The first prevents a flawed libgcc_s.so.1 from getting built
for gcc 3.2. The second prevents bogus link errors against
glibc 2.2.5-14 when building with gcc 2.95.4.
Reply to: