At Thu, 13 Feb 2003 13:43:24 -0800,
Ryan Murray wrote:
> [1 <text/plain; us-ascii (quoted-printable)>]
> On Fri, Feb 14, 2003 at 02:10:59AM +0900, GOTO Masanori wrote:
> > At Thu, 13 Feb 2003 08:48:14 -0600,
> > Debian Bug Tracking System wrote:
> > > Processing commands for [EMAIL PROTECTED]:
> > >
> > > > reassign 179781 glibc
> > > Bug#179781: dcgui: relocation error: /usr/bin/dcgui: undefined symbol:
> > > __fixunsdfdi
> > > Bug#180330: libc6, relocation error (dcgui)
> > > Bug reassigned from package `gcc-3.2' to `glibc'.
> > >
> > > > severity 179781 serious
> > > Bug#179781: dcgui: relocation error: /usr/bin/dcgui: undefined symbol:
> > > __fixunsdfdi
> > > Bug#180330: libc6, relocation error (dcgui)
> > > Severity set to `serious'.
> > >
> > > > merge 179781 178645
> > > Bug#178645: glibc: needs to export __umoddi3 et al. on sparc
> > > Bug#179781: dcgui: relocation error: /usr/bin/dcgui: undefined symbol:
> > > __fixunsdfdi
> > > Mismatch - only Bugs in same state can be merged:
> > > Values for `package' don't match:
> > > #178645 has `libc6';
> > > #179781 has `glibc'
> >
> > I'm sorry, but I still don't understand why #179781 is glibc bug?
>
> It's the only place we can workaround it easily. It is the same bug
> as #178645, and we talked about this in IRC.
>
> > #179781 says that this bug forcuses __fixunsdfdi and __fixunssfdi are
> > appeared as .hidden attribute functions. Please test below code
>
> Yes, and the exact same thing happens with #178645. These are identical bugs,
> with different libgcc symbols.
>
> > "gcc -S abovecode.c" says there is "__fixunsdfdi .hidden attribute".
>
> Yes, that's as it should be.
I still wonder why .hidden __fixdfdi (*signed* long long int -> double)
is not appeared, but .hidden __fixunsdfdi (*unsigned* long long int ->
double) is appeared. Try:
main()
{
unsigned long long a;
signed long long c;
double b;
a=b;
c=b;
}
You can see __fixunsdfdi, but not __fixdfdi. Apparently __fixdfdi is
expanded, but __fixunsdfdi is not. I worry about #179781 that the
current gcc-3.2 with the current glibc generate __fixunsdfdi. I would
like to know is:
1. Why is __fixunsdfdi appeared, on the contrary why is not __fixdfdi
appeared
2. Are there any problems to appear __fixunsdfdi?
3. libgcc-compat resolves this apprearing __fixunsdfdi? (I don't think so)
> > I heard libgcc-compat for i386 was needed for the current debian-glibc,
> > but is this libgcc-compat patch resolves #179781 __fixunsdfdi .hidden
> > attribute problem?
>
> It's needed on every arch.
>
> > Woody gcc-2.95.4 with libc6 2.2.5-11.2 output '.globl __cmpdi2'
> > instead of '.globl __fixunsdfdi', and this symbol is ok to resolve on
> > the current sid debian environment (so we can run such binaries).
>
> Yes, but this is incorrect, and this bug has been fixed in gcc. We now
> have to handle transitioning from the old libraries (linktime-available
> symbols in every lib that happens to use them) to the new ones (no
> linktime-available versions).
Ah, I see.
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.
> > Another question is: which symbols should we add for i386 libgcc-compat?
>
> An archive walk against woody needs to be done on the missing archs to
> see which symbols were leaked by this.
Thanks to Guido and Ryan, I see they're in libgcc and they aren't in
sysdeps/wordsize-32/*. I wonder why upstream has not been added such
leaked symbols. If it's critical things, we should submit ASAP.
Or, upstream thinks another way to fix?
> > Please lead/explain to me...
>
> <neuro> what's happening here is that random-other-library-named-libfoo was
> built with 2.95, and needs libgcc
> <neuro> the symbols were not marked as hidden there, and you end up with them
> in the shared lib
> <neuro> when they get recompiled with 3.2, they are correctly hidden
> <neuro> binaries that link against them, however, will have linked with the
> shared symbol, which has been hidden.
>
> We are putting the compat symbols in glibc, rather than every library that
> might have linked with a libgcc symbol. All of the merged bugs are caused
> by this problem. I don't see how you can understand that #178645 is a
> glibc problem, but not #179781. They are the same problem, with different
> symbols from the same library.
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.
Sorry my repeatedly question, but I still don't find "what is the real
problem"... At least in my environment, gtk+ and recompiled dcgui
works fine.
Thanks in advance,
-- gotom
