[wiget@pld.org.pl] libc/3237: symbol __udivdi3, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

Jakub Jelinek jakub@redhat.com
Fri Apr 12 11:52:00 GMT 2002


On Fri, Apr 12, 2002 at 11:36:25AM -0700, Ulrich Drepper wrote:
> On Fri, 2002-04-12 at 11:28, Franz Sirl wrote:
> 
> > [fsirl@entropy:~/rh70/glibc/RPMS/ppc]$ readelf -a ./lib/libc-2.2.5.so |egrep 
> > '(moddi3|divdi3)'
> >   3444: 001123a0  1176 FUNC    LOCAL  DEFAULT   10 __divdi3
> >   3769: 00113094   912 FUNC    LOCAL  DEFAULT   10 __umoddi3
> >   3775: 00112c9c  1016 FUNC    LOCAL  DEFAULT   10 __udivdi3
> >   4414: 00112878  1060 FUNC    LOCAL  DEFAULT   10 __moddi3
> 
> Which symbol table is this from?

As no symbol is there twice and my i686 libc has < 2100 .dynsym entries,
I bet this is .symtab.
The interesting thing is what library the library or program
took the *{div,mod}di3 from and is not any longer when libgcc.a has all
these .hidden.
I bet the situation is like on IA-64 - exporting those symbols (which are
in glibc local anyway) as non-default @GLIBC_2.0 symbols (to match
what libgcc_s.so.1 does) for binary compatibility would cure all
of this, but newly compiled libraries/binaries would
always use their own local version.

	Jakub



More information about the Libc-alpha mailing list