To give you fellows a better idea of the symbol issues we are
dealing with on powerpc in glibc for the transition to gcc 3.2,
consider the differences below...
for stock glibc 2.2.5-13 (no libgcc-compat code at all)...
[EMAIL PROTECTED]:~$ objdump --dynamic-sym /lib/libc.so.6 | grep __divdi3
[EMAIL PROTECTED]:~$
...no symbols in /lib/libc.so.6 for __divid3.
for glibc 2.2.5-13 plus the glibc-2-2-branch version of the libgcc-compat
code...
[EMAIL PROTECTED]:~$ objdump --dynamic-sym /lib/libc.so.6 | grep __divdi3
000266b0 g DF .text 000000c8 GLIBC_2.0 __divdi3
...a __divdi3 exported for linking and run-time resolution.
^^^^^^^^^^^^^^^^^^^^
for a glibc 2.2.5-13 plus the proposed new libgcc-compat code
(libgcc-compat.S instead of libgcc-compat.c)...
[EMAIL PROTECTED]:~$ objdump --dynamic-sym /lib/libc.so.6 | grep __divdi3
00026680 g DF .text 000000c8 (GLIBC_2.0) __divdi3
...a __divdi3 NOT exported for linking BUT available for run-time
resolution (note "()"s on the GLIBC_2.0 versioning).
When the libgcc-compat code was discussed one demand Ulrich
had was that all the libgcc-compat symbols must NOT be exported for
linking! So we really want to avoid using current glibc-2-2-branch's
sysdeps/powerpc/libgcc-compat.c but use the sysdeps/powerpc/libgcc-compat.S
version instead. Otherwise we will start, temporarily until the correct
fix goes into glibc, exporting __divdi3 for linking from libc.so.6
and then stop when the fix goes in. It is better to skip this potential
breakage and adopt the correct fix.
Again note that the correct fix in the upcoming patch,
glibc-libgcc-compat-ppc-8-2_2d, from Franz Sirl avoids this issue
by only making the __divdi3, and several other symbols, available
for run-time resolution and NEVER for linking from inside glibc.
The libgcc-compat.S version also is optimized which the old one isn't.
Thanks in advance again.
Jack
