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

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

Hi Guido,
Thanks for your explanation.

At Sun, 16 Feb 2003 23:32:42 +0100,
Guido Guenther wrote:
> I'm trying to explain how I understand these issues, but it might not be
> correct:
> 
> On Mon, Feb 17, 2003 at 12:49:44AM +0900, GOTO Masanori wrote:
> >  1. Why is __fixunsdfdi appeared, on the contrary why is not __fixdfdi
> >     appeared
> gcc does the double -> signed long long conversion inline but uses a
> function call for the unsigned conversion.

Hmm, I feel it's strange feature... There are no need to distinguish 
between signed and unsigned.  Is it gcc bug?

> >  2. Are there any problems to appear __fixunsdfdi?
> Don't think so. Have a look at the binary with readelf. The linker
> produces an entry with visibility hidden (which is what he should do) or
> a relocation entry and an undefined reference when linking against
> libgcc_s. I think that's fine.

Thanks, I don't mind the .hidden appearance any more.

> >  3. libgcc-compat resolves this apprearing __fixunsdfdi? (I don't think so)
> No the symbol comes from libgcc.a or libgcc_s.so if you link with
> -lgcc_s
>
> [..snip..]
> > But, I would like to know is "what package is caused problems without
> > libgcc-compat patch".  At least, ".globl __cmpdi2" appeared binaries
> > works fine on sid.
> For example:
> /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?

> from woody. Then do a: 
>   LD_BIND_NOW=TRUE LD_DEBUG=bindings strip 2>&1 | grep udivdi
> and you see:
> 
> 25327:	binding file /lib/libc.so.6 to /usr/lib/libbfd-2.13.90.0.4-multiarch.so: normal symbol `__udivdi3' [GLIBC_2.0]
> 25327:	binding file /usr/lib/libbfd-2.13.90.0.4-multiarch.so to /usr/lib/libbfd-2.13.90.0.4-multiarch.so: normal symbol `__udivdi3'
> 25327:	binding file strip to /usr/lib/libbfd-2.13.90.0.4-multiarch.so: normal symbol `__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]

> on recompilation of libbfd with gcc-3.2/glibc-2.3.1 these symbols aren't
> reexported by libbfd anymore and strip starts to fail [1]

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?

> [..snip..]
> > Well, dcgui (#179781) should be fixed with the latest glibc and gcc
> > environment.  Moreover, if binaries on woody/sarge works well, then I
> > think we should not add this compat-patch even if sid binaries causes
> > such unresolved symbol bug.
> No. We only add symbols for the woody->sarge transition.

So, is it debian specific patch?

> [1] the point here is a bit moot since strip and libfd are in the same
> package but it shows the principle.

I'm sorry again, but I would like to know about it deeper and deeper,
and I also would like to make it clean...

Regards,
-- gotom