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] |
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] |