Re: Processed: reassign 179781 to glibc, severity of 179781 is serious, merging 179781 178645

[Guido Guenther <agx@debian.org>]

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