reassign 427185 gcc-4.1
thanks
On Sun, Jun 03, 2007 at 03:39:25PM +0200, Matthias Klose wrote:
> unreproducible; works for me in a current unstable environment.
I've just updated again to current unstable (only portmap and findutils
changed) and can still reproduce the problem:
| broonie@lorien:/tmp$ cat foo.c
| int main(void)
| {
| return 0;
| }
| broonie@lorien:/tmp$ gcc -m64 -o foo foo.c
| /usr/bin/ld: error in /usr/lib/gcc/i486-linux-gnu/4.1.3/64/crtend.o(.eh_frame); no .eh_frame_hdr table will be created.
| broonie@lorien:/tmp$ echo $?
| 0
and similarly if I compile to an object and link that. Reassigning back
to gcc-4.1 since it can be reproduced outside of the zlib build
environment - whatever is going on here doesn't appear to be related to
that package.
Perhaps we have somehow managed to get different versions of some
toolchain packages? I have:
ii binutils 2.17cvs2007042 The GNU assembler, linker and binary utiliti
ii binutils-multi 2.17cvs2007042 Binary utilities that support multi-arch tar
(these are both at 2.17cvs20070426-8.)
ii gcc-4.1 4.1.2-11 The GNU C compiler
ii gcc-4.1-multil 4.1.2-11 The GNU C compiler (multilib files)
ii gcc-multilib 4:4.1.2-2 The GNU C compiler (multilib files)
ii libc6-dev 2.5-9+b1 GNU C Library: Development Libraries and Hea
ii libc6-dev-amd6 2.5-9+b1 GNU C Library: 64bit Development Libraries f
ii libc6-i686 2.5-9+b1 GNU C Library: Shared libraries [i686 optimi
and apt currently claims that none of the packages on that system are
out of date. I don't know what the buildd that was used for the
original report had. Removing binutils-multiarch appears to have no
effect on the problem.
--
"You grabbed my hand and we fell into it, like a daydream - or a fever."
Attachment:
signature.asc
Description: Digital signature