This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

I think that's what I've seen when I tried that, iirc.

Franz.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]