[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: How to get Debian to gcc-3.2 ....



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.



Reply to: