Martin, I think the primary problem debian will have with gcc 3.2 (or 3.1.1 for that matter) is dealing with rebuilding glibc under it. Because the gcc 3.1 fixed a bug relating to incorrectly linking in libgcc symbols into binaries, glibc trunk and glibc-2-2-branch have fixes to address this through a new libgcc-compat file on ppc. Other arches may have handled this issue in a slightly different manner. Basically on ppc, we make sure that these libgcc symbols that were improperly linked in by gcc < 3.1 are exported from glibc now but only for resolving and not for linking. The problem I see if that it is unclear how many arches for linux have had these changes made. The basic approach is to search all the binaries on a arch for libgcc symbols and when you have the list create a libgcc-compat that provides them for resolving but not for linking. Again without this addition to glibc for every arch debian has you will get massive breakage of existing binaries when you install a gcc > 3.1 built glibc. With it, the problem is a non-issue. As I said these changes have been made in glibc-2-2-branch for ppc, but I'm unclear how many other arches have have the changes migrated back from the glibc cvs trunk into glibc-2-2-branch. Jack ps You can see the overall scheme of this from...
http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/powerpc/libgcc-compat.c?rev=1.1.2.3&content-type=text/x-cvsweb-markup&cvsroot=glibc&only_with_tag=glibc-2-2-branch http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/sysdeps/powerpc/Versions.diff?r1=1.2&r2=1.2.2.1&cvsroot=glibc&only_with_tag=glibc-2-2-branch -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]