This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu
- From: Jack Howarth <howarth at bromo dot msbb dot uc dot edu>
- To: Franz dot Sirl-kernel at lauterbach dot com, gcc-patches at gcc dot gnu dot org
- Date: Mon, 12 Aug 2002 19:31:39 -0400 (EDT)
- Subject: Re: [PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu
Franz,
I think it would be helpful if we reviewed the discussion in the
past in light of the recent binutils fixes. In particular, see message...
http://gcc.gnu.org/ml/gcc-patches/2002-08/msg00374.html
Jakub's suggestion that...
> I thought glibc was exporting those at a different version on ppc. Now
> that I see it is @@GLIBC_2.0, I really don't see why it should be moved to
> GCC_3.0 symver unless this is for pure esthetical reasons, you just
> eventually remove @@GLIBC_2.0 export from glibc and convert that to
> @GLIBC_2.0. Libraries linked with -lc -lgcc_s would still work (they can
> choose whether they'll use the symbols from glibc or libgcc_s), libraries
> linked with -lc -lgcc (horribly broken) can still be satisfied with the
> future @GLIBC_2.0 export from glibc.
is now valid as the linker no longer complains about duplicate
__divdi3@GLIBC_2.0 symbols when using the current libgcc-compat
code in glibc-2-2-branch in a gcc 2.95.4 or 3.1.1/3.2 built glibc
to build new programs with gcc 2.95.4.
Assuming that issue is fixed, can you help define situations where
pre-existing binaries will break when runing a glibc with the current
libgcc-compat code in glibc-2-2-branch. I haven't seen this situation
occur on debian ppc sid when I ran either a gcc 2.95.4 built or 3.1.1.
built glibc with the libgcc-compat changes from glibc-2-2-branch.
In short I am wondering what level of breakage really still exists if
any?
Jack