[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