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

["H. J. Lu" <hjl at lucon dot org>]

On Tue, Aug 06, 2002 at 11:47:00PM +0200, Franz Sirl wrote:
> On Dienstag, 6. August 2002 23:23, Jakub Jelinek wrote:
> > On Tue, Aug 06, 2002 at 11:13:10PM +0200, Franz Sirl wrote:
> > > But I don't want these symbols to resolve to the glibc versions, except
> > > for backwards compatibility. They should resolve to libgcc_s and should
> > > clearly state that. As stated in a followup message, the current setup
> > > already caused problems and I want to avoid this problems once and
> > > forever. 3.2 is the ideal candidate for such a change.
> > >
> > > So in the future glibc will export these symbols only as a runtime
> > > reference __divdi3@GLIBC_2.0 and libgcc_s will contain the linktime
> > > reference @@GCC_3.0 and the runtime reference @GLIBC_2.0. IMHO this is
> > > how it always should have
> >
> > 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.
> 
> Doesn't that setup cause the linker to complain like that:
> 
> /lib/libgcc_s.so.1(*IND*+0x0): multiple definition of `__divdi3@GLIBC_2.0'
> /lib/libc.so.6(.text+0x574): first defined here

That can be a linker bug. I will see if I can come up with a small
testcase and fix it.


H.J.