[wiget@pld.org.pl] libc/3237: symbol __udivdi3, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
Franz Sirl
Franz.Sirl-kernel@lauterbach.com
Mon Apr 15 02:52:00 GMT 2002
At 20:44 12.04.2002, Jakub Jelinek wrote:
>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.
Sounds like it. As it turns out it's not glibc's fault at all, but the
problem is in the way openssl builds it's shared libs:
gcc -shared -o libcrypto.so.0.9.6 -Wl,-S,-soname=libcrypto.so.2
-Wl,--whole-archive libcrypto.a -Wl,--no-whole-archive -L. -lc
With gcc-2.95 this pulls in __umoddi3 and __udivdi3 from libgcc.a (and in
2.95 these symbols are not tagged with .hidden) and then re-exports them
(which seems to be a perfectly normal thing for ld to do, if I'm
interpreting the docs correctly).
With gcc-3.1 these symbols are tagged with .hidden in libgcc.a and thus ld
does not re-export them.
Does this sound like a correct analysis? What shall we do here? Add the
libgcc symbols to glibc as Jakub suggested or change the way gcc-3.1 builds
libgcc.a?
Franz.
More information about the Libc-alpha
mailing list