Re: provide symbols .hidden in gcc 3.1/3.2 when building glibc for ppc
If possible, I'm going to wait for HJ to spin another release of binutils
before uploading anything post-2.12.92.0.15. It shouldn't be long. Once
he's made another one, I've got the rest of the bits ready to go, so I can
probably do the upload for this within a day.
What's our time frame for starting the gcc-3.2 migration?
In the meantime, I'm building 2.12.92.0.15-2 right now that addresses a
few of the outstanding bugs in the BTS (modutils conflicts, etc). I'm
hoping the builds will be done in time for an upload by 1pm today.
C
On Tue, 13 Aug 2002, Jack Howarth wrote:
> 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)...
>
> howarth@bogus:~$ objdump --dynamic-sym /lib/libc.so.6 | grep __divdi3
> howarth@bogus:~$
>
> ...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...
>
> howarth@bogus:~$ 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)...
>
> howarth@bogus:~$ 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
>
>
> --
> To UNSUBSCRIBE, email to debian-gcc-request@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact listmaster@lists.debian.org
>
>
>
Reply to: