Jan, There definitely will be an issue with rebuilding glibc against either gcc 3.1.1 or 3.2 on at least two, if not more, arches. The problems arise from the change in gcc 3.1 which makes libgcc symbols .hidden now. This means that if you rebuild the current glibc 2.2.5-13 with gcc 3.1.1/3.2, old binaries will no longer have these symbols resolved for them if linked in. Currently we have a first generation patch checked into glibc-2-2-branch that addresses this on ppc. I believe ia64 only has this change in the main trunk and not backported into glibc-2-2-branch. Franz Sirl just completed a new version of the libgcc-compat patch for glibc-2-2-branch that hasn't made it in yet. The new version is coupled with a versioning fixup for gcc 3.2 which will keep the versioning the same for these libgcc symbols as it was under gcc 2.95.4. Unfortunately this change tickled a bug in binutils which HJ Lu has tentatively fixed and will be in the next binutils. If all goes well, on ppc at least, we should have the second generation libgcc-compat patch in glibc-2-2-branch, the versioning fixup in gcc 3.2 and all the fixes needed in the next binutils from HJ Lu. If you want to read up on these the related threads are...
http://sources.redhat.com/ml/libc-alpha/2002-04/msg00025.html ...original description of the problems with the .hidden symbols was found in this thread (in a convoluted discussion)... http://sources.redhat.com/ml/libc-alpha/2002-05/msg00067.html ...development of the 1st generation libgcc-compat patch on ppc is in this thread... http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00252.html ...thread describe Franz's proposed fixup for the gcc 3.2 libgcc symbol versioning... http://sources.redhat.com/ml/binutils/2002-08/msg00173.html http://sources.redhat.com/ml/binutils/2002-08/msg00173.html http://sources.redhat.com/ml/binutils/2002-08/msg00175.html ...threads describing the binutils bug we tickled when moving to Franz's new revised libgcc-compat patches. For non-ppc arches the binutils stuff probably isn't of interest except that we found some real binutils bugs and got them fixed. However each debian arch will need to evaluate if they have to deal with the .hidden libgcc symbols by adding a libgcc-compat patch to glibc 2.2.5. Again so far glibc-2-2-branch only has this addressed (and not in the most updated form) for ppc. You could look in glibc main trunk and see if any other arches besides ia64 have added patches there as the form is essentially the same in 2.2.90 or 2.2.5. I am hoping we can have ppc go first to gcc 3.2 as we seem to been most aggressive in addressing these backward compatibility issues with libgcc symbols in glibc and should be able to rely on stock release gcc 3.2, release binutils and current glibc-2-2-branch cvs to get all the appropriate fixes in place. Jack ps I have been testing HJ Lu's new binutils fixes to 2.13.90.0.3 with Franz's most recent libgcc-compat patches applied to glibc 2.2.5-13 this weekend. I am able to build binutils and glibc with all passing make check fine. I also just built gcc 3.2 with Franz's proposed fixup for symbol versioning and the resulting test-summary looks fine as well. The gcc failures I get are... FAIL: gcc.dg/20020103-1.c scan-assembler-not LC FAIL: gcc.dg/20020118-1.c execution test FAIL: gcc.dg/format/ext-3.c bad %^# (test for warnings, line 215) FAIL: gcc.dg/format/ext-3.c (test for excess errors) ...unexpected only of course. The rest all look identical to what I get for gcc 3.1.1.
