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)... > > [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 > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > >
