[PATCH] 3.2: Fixup symbol versioning mistake on powerpc-linux-gnu

[Jack Howarth]

Jakub,
    When you said...

This is not how the linker works.
When building libgcc_s, -lc comes after all the libgcc/./*{div,mod}di3.o
which means the symbols are exported from both glibc and
libgcc_s (with the same version):
On IA-32 where gcc has been built a couple of times since that glibc was
installed:
$ readelf -s /lib/libc.so.6 | grep moddi3
   701: 00016ad0    55 FUNC    GLOBAL DEFAULT   11 __umoddi3@@GLIBC_2.0
  1856: 00016a10   128 FUNC    GLOBAL DEFAULT   11 __moddi3@@GLIBC_2.0
$ readelf -s /lib/libgcc_s.so.1 | grep moddi3
    46: 00002788    38 FUNC    GLOBAL DEFAULT   11 __umoddi3@@GLIBC_2.0
    95: 000021c0   240 FUNC    GLOBAL DEFAULT   11 __moddi3@@GLIBC_2.0
So either you run into yet another linker bug, or you have
some pieces of your patch applied to the gcc tree you were testing.

...what did you mean by another linker bug. We did in fact run into
a linker bug where using Franz's new revised libgcc-compat patches
and gcc 2.95.4 to build programs, we did indeed run into symbol conflicts
in binutils. HJ Lu has test cased this situation and fixed it in binutils
cvs...

http://sources.redhat.com/ml/binutils/2002-08/msg00190.html
http://sources.redhat.com/ml/binutils/2002-08/msg00180.html
http://sources.redhat.com/ml/binutils/2002-08/msg00175.html

I have locally confirmed this binutils change eliminates the
problem and I can now use a glibc with Franz's new libgcc-compat
changes to build programs with gcc 2.95.4 without symbol conflicts.
I have also built gcc 3.2 with Franz's proposed symbol versioning
fixup against the same glibc 2.2.5 (with new libgcc-compat patches)
and the new patched binutils. The resulting gcc 3.2 builds fine and
passes make check fine as well. I don't think we have to worry about
breakage now but rather if the change in symbol versioning is merited.
                          Jack