Hi Guido! At Mon, 17 Feb 2003 15:27:05 +0100, Guido Guenther wrote: > 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
I finally found why my woody machine did not show such result. Your "strip" is "binutils-multiarch". I tested with "strip" of "binutils". > > 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. Greatly thanks to Guido and Ryan for your kindly explanation in spite of my repeatedly questions, now I obviously understand what has happened. Yes, that's needed for debian specific transition from woody to sid for some binaries. Apparently we have not known such problem package except for dcgui, but some user-built-binaries may cause this issue. OK, now I've commited your dpatch in debian-glibc cvs, and drop your libgcc-compat-mips/sparc. If we get this kind of unresolved symbol error report for other architecture, then we simply add libgcc-compat patch. At last I can say it's time to go -12 and open the sarge's door :) Thanks, -- gotom
