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

re: Coexistence of gcc 3.2 and gcc 2.95



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 debian-gcc-request@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org



Reply to: