[wiget@pld.org.pl] libc/3237: symbol __udivdi3, version GLIBC_2.0 not defined in file libc.so.6 with link time reference
H . J . Lu
hjl@lucon.org
Fri Apr 12 11:36:00 GMT 2002
On Fri, Apr 12, 2002 at 08:28:36PM +0200, Franz Sirl wrote:
> On Friday 12 April 2002 20:09, Geoff Keating wrote:
> > > From: Franz Sirl <Franz.Sirl-kernel@lauterbach.com>
> > > Date: Fri, 12 Apr 2002 18:41:15 +0200
> > >
> > > The same just happened to me, I guess this means I have to add divdi3.c
> > > to sysdeps/powerpc/Makefile?
> >
> > Yes, if it was once exported it has to be included forever.
>
> Hmm, Jakub may have a point though, I wonder why this happened at all:
>
> This is the gcc-2.95.4 compiled glibc sendmail was compiled against:
>
> [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
>
> And is the now-installed gcc-3.1 compiled glibc:
>
> [fsirl@entropy:~/rh70/glibc/RPMS/ppc]$ readelf -a /lib/libc-2.2.5.so |egrep
> '(moddi3|divdi3)'
> 2367: 0010310c 220 FUNC LOCAL HIDDEN 10 __divdi3
> 2692: 00104140 44 FUNC LOCAL HIDDEN 10 __umoddi3
> 2698: 00103c58 36 FUNC LOCAL HIDDEN 10 __udivdi3
> 3337: 001036ac 232 FUNC LOCAL HIDDEN 10 __moddi3
>
> Shouldn't have ld used the symbols from libgcc.a instead of the LOCAL symbol
> from glibc? Or does LOCAL/HIDDEN make the difference here? But then why
> should it take __divdi3/__moddi3 from libgcc.a, but __udivdi3/__umoddi3 from
> libc.so?
ld shouldn't use any hidden symbols to resolve symbol references. Send
me a testcase if it does.
H.J.
More information about the Libc-alpha
mailing list