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.