This is the mail archive of the libc-alpha@sources.redhat.com mailing list for the glibc 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] PPC libgcc compatibility


On Wednesday 15 May 2002 21:04, Franz Sirl wrote:
> On Wednesday 15 May 2002 14:58, Jakub Jelinek wrote:
> > On Wed, May 15, 2002 at 02:50:53PM +0200, Franz Sirl wrote:
> > > At 14:44 15.05.2002, Jakub Jelinek wrote:
> > > >On Wed, May 15, 2002 at 02:41:59PM +0200, Franz Sirl wrote:
> > > > > extern int64_t __fixdfdi (double);
> > > > >
> > > > > int64_t INTUSE (__fixdfdi) (double d)
> > > > > {
> > > > >    return __fixdfdi (d);
> > > > > }
> > > > > symbol_version (INTUSE (__fixdfdi), __fixdfdi, GLIBC_2.0);
> > > >
> > > >The linker won't let you do that I'm afraid.
> > >
> > > Really? I just tried it and glibc linked fine (binutils-2.12.90.0.7).
> > > Which linker error would you expect?
> >
> > If it was the default version, linker would certainly not be happy at
> > all, but apparently if it is non-default version, it might work.
> > In that case, it would make sense to change the IA-64 bits the same way
> > (though I think we should keep divdi3.c as it should be more efficient
> > than what libgcc has). Currently e.g. __divtf3 is compiled into glibc
> > twice on IA-64, once for the export and once hidden, since for the export
> > it is not the default version and thus linker puts in libgcc.a too.
>
> The appended patch against the branch works fine, but I noticed a new
> problem, since in gcc we have that for libgcc_s.so.1 in
> gcc/config/libgcc-glibc.ver:
>
> %inherit GCC_3.0 GLIBC_2.0
> GLIBC_2.0 {
>   # Sampling of DImode arithmetic used by (at least) i386 and m68k.
>   __divdi3
>   __moddi3
>   __udivdi3
>   __umoddi3
>
> Now ld complains when linking shared c++ libs :-(. Now, what can we do? Can
> I use GLIBC_2.1 as a version in glibc instead? Or maybe even a special
> GLIBC_COMPAT?

Ok, if I keep divdi3 all is well, I don't understand why, but no more 
complaints about doubled definitions between glibc and libgcc_s linking 
shared c++ libs.

Uli, unless 2.3 is very close, it would be nice if this could go on the branch 
too.

I leave the decision on what to do with the now superflous cmpdi2.c etc. to 
you.

Franz.


	* sysdeps/powerpc/Makefile (sysdeps_routines): Use libgcc-compat instead
	of cmpdi2, shdi3, fixdfdi, fixsfdi in csu dir.
	(shared-only-routines): Likewise.
	* sysdeps/powerpc/libgcc-compat.c: New file.

Attachment: glibc-libgcc-compat-ppc-6.patch
Description: Text document


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