On Mon, Feb 17, 2003 at 10:58:21PM +0900, GOTO Masanori wrote: [..snip..] > > /usr/bin/nm __udivdi3 > > /usr/bin/nm __umoddi3 > > /usr/bin/strip __ucmpdi2 > > /usr/bin/strip __udivdi3 > > I'm sorry, but I can't understand what you mean... You mean that a binary > has _udivdi3 or __umoddi3 and then drops its symbol with strip? readelf -a /usr/bin/strip | grep __udivd 08079fa4 00002c07 R_386_JUMP_SLOT 08049d84 __udivdi3 44: 08049d84 282 FUNC GLOBAL DEFAULT UND __udivdi3
> My strip says: > > bash-2.05a$ LD_BIND_NOW=TRUE LD_DEBUG=bindings strip 2>&1 |grep udivdi > 29816: binding file /lib/libc.so.6 to /lib/libc.so.6: normal symbol > `__udivdi3' [GLIBC_2.0] O.k., I have slightly newer binutils here (2.13.90.0.4-1). Anyway the point below stays valid: [..snip..] > I would like to know is "what package name is caused" with this > problem... you mean that binutils.deb does not work on sid? At least > woody's binutils works on my sid... Or user compiled binaries/libraries? Not exactly, that's what the footnote in my last mail tried to make clear - as long as the library and the binary are in the same package you won't notice any problems (which is the case for strip/libbfd) - it was just an example. - __udivdi3 is already provided by our glibc as @GLIBC_2.0 on *i386* but not for other architectures, we explicitly have to make it available via sysdeps/arch/Versions - have a look at the patch: http://honk.physik.uni-konstanz.de/linux-mips/glibc/patches/experimental/libgcc-compat-all.dpatch and look for compat_symbol, also compare e.g. sysdeps/sparc/Versions and sysdeps/i386/Versions - i386 already makes some of the symbols available in upstream glibc but we need them on other architectures as well. Regards, -- Guido
