Re: Processed: reassign 179781 to glibc, severity of 179781 is serious, merging 179781 178645
Hi Gotom,
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.
> 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.
> 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
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'
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]
[..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.
Regards,
-- Guido
[1] the point here is a bit moot since strip and libfd are in the same
package but it shows the principle.
Reply to: