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

[GOTO Masanori <gotom@debian.or.jp>]

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