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 control@bugs.debian.org: > > > > > 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 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). > 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. > 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. -- Ryan Murray, Debian Developer (rmurray@cyberhqz.com, rmurray@debian.org) The opinions expressed here are my own.
Attachment:
pgpdl9tdywSS1.pgp
Description: PGP signature