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


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.


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