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: [wiget@pld.org.pl] libc/3237: symbol __udivdi3, version GLIBC_2.0 not defined in file libc.so.6 with link time reference


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


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