| Summary: | kde-base/libkpgp-4.4.9 fails top build on x86 | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Andreas Schürch <nativemad> |
| Component: | New packages | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
| Status: | RESOLVED NEEDINFO | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | build.log | ||
|
Description
Andreas Schürch
2011-01-27 14:14:08 UTC
Created attachment 260871 [details]
build.log
> Linux-2.6.34-gentoo-r6-i686-QEMU_Virtual_CPU_version_0.12.5-with-gentoo-1.12.14 > gmake: *** [cmTryCompileExec/fast] Illegal instruction Somehow I don't think it's a Gentoo problem. (In reply to comment #2) > Somehow I don't think it's a Gentoo problem. That's a good catch! I've copied the install over to a directory on the hostsystem and `linux32 chroot .`ed to that, but i get exactly the same! Portage 2.1.9.25 (default/linux/x86/10.0, gcc-4.4.4, glibc-2.11.2-r3, 2.6.34-gentoo-r1 i686) ================================================================= System uname: Linux-2.6.34-gentoo-r1-i686-Intel-R-_Core-TM-2_Quad_CPU_Q6600_@_2.40GHz-with-gentoo-1.12.14 Timestamp of tree: Thu, 27 Jan 2011 06:00:01 +0000 distcc 3.1 i686-pc-linux-gnu [disabled] app-shells/bash: 4.1_p9 dev-java/java-config: 2.1.11-r3 dev-lang/python: 2.6.6-r1, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.14-r1 sys-apps/sandbox: 2.4 sys-devel/autoconf: 2.13, 2.65-r1 sys-devel/automake: 1.8.5-r4, 1.9.6-r3, 1.10.3, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 (sys-kernel/linux-headers) The Host system: Portage 2.1.8.3 (default/linux/amd64/10.0/server, gcc-4.4.4, glibc-2.11.2-r0, 2.6.34-gentoo-r1 x86_64) ================================================================= System uname: Linux-2.6.34-gentoo-r1-x86_64-Intel-R-_Core-TM-2_Quad_CPU_Q6600_@_2.40GHz-with-gentoo-1.12.13 Timestamp of tree: Thu, 27 Jan 2011 06:00:01 +0000 app-shells/bash: 4.1_p7 dev-lang/python: 2.6.5-r3, 3.1.2-r4 dev-util/cmake: 2.8.1-r2 sys-apps/baselayout: 1.12.13 sys-apps/sandbox: 2.3-r1 sys-devel/autoconf: 2.65-r1 sys-devel/automake: 1.9.6-r2, 1.10.2, 1.11.1 sys-devel/binutils: 2.20.1-r1 sys-devel/gcc: 4.4.4-r2 sys-devel/gcc-config: 1.4.1 sys-devel/libtool: 2.2.10 sys-devel/make: 3.81-r2 virtual/os-headers: 2.6.30-r1 First see if either VERBOSE=1 makes cmake print the failing command or if there's a temporary file with the command, that failed. We need to make sure what CFLAGS exactly get used in that check. This is now really strange! I haven't done anything on the VM and now it works!? But it still gives the same error within the chroot that was copied yesterday. On a new copy, it works!? -Now the very weird part: an "rsync -rlvopgtD /workingchroot /oldchrootfromyesterday" doesn't solve the problem!? But a "rsync -rlvopgtD /workingchroot /newdir" produces a working copy. I tried it with "VERBOSE=1 emerge libkpgp" on the old chroot but i get exactly the same output. In dmesg on the hostmachine i get for every try a line like: gmake[8666] trap invalid opcode ip:8049afb sp:ffd88acc error:0 in gmake[8048000+23000] But i've got nothing like that within the VM. I find it also a bit confusing that i get "tar extract command failed at least partially - continuing anyway" on both, the working VM/chroot and the non-working chroot. I'm using an nfs-shared portage-tree, so the distfiles and so on are the same! I wonder what corrected the issue on the VM!? makewhatis from cron wasn't guilty... Any other ideas? I tried, but not reproducible for me during archtesting of kdepim-4.4.9 (In reply to comment #5) > But it still gives the same error within the chroot that was copied yesterday. > On a new copy, it works!? -Now the very weird part: an "rsync -rlvopgtD > /workingchroot /oldchrootfromyesterday" doesn't solve the problem!? > But a "rsync -rlvopgtD /workingchroot /newdir" produces a working copy. OK, so the old chroot from yesterday is plain broken, maybe something went wrong in copying stuff over. > In dmesg on the hostmachine i get for every try a line like: > gmake[8666] trap invalid opcode ip:8049afb sp:ffd88acc error:0 in > gmake[8048000+23000] > But i've got nothing like that within the VM. The "VM" / kernel apparently doesn't get to know what an illegal instruction is. > I find it also a bit confusing that i get "tar extract command failed at least > partially - continuing anyway" on both, the working VM/chroot and the > non-working chroot. That's unrelated. > I wonder what corrected the issue on the VM!? makewhatis from cron wasn't > guilty... Any other ideas? Well, when you do get some more ideas on how to /reproduce/ this, and you think it's important enough, then please note them here and reopen this bug report. I think looking into hardware errors (faulty RAM mainly) should prove more fruitful than treating this as a software issue. |