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