After searching around on bugs.gentoo.org I can only find compilation-problems with regards to qemu and why we are filtering hardened flags. Well, trying with hardened gcc-3.4 and hardened gcc-4 this filtering is not needed any more. As I can read the thing that did not want to compile with hardened was dyngen, and it seems like when upstream dumped dyngen they also dumped all problems compiling qemu on hardened. I have as pointed out built it with hardened gcc-3.4 and gcc-4.3.3 without filtering in a 32-bits and 64-bits userland. Both completed fine and it seems to run fine also. To be honest it did not even build on hardened 64-bit no matter version of gcc with filtering, so I think the filtering is a good thing to remove.
*** Bug 271360 has been marked as a duplicate of this bug. ***
Confirmed. I'm running amd64 hardened gentoo with no multilib and compiled qemu-0.10.5 by removing filter-flags from the ebuild. However qemu-softmmu-0.9.1-r3 would not compile due to some issue with dyngen, like Xake said. It gets a little furthur with filter-flags off, but then fails at dyngen. $ gcc --version gcc (GCC) 3.4.6 (Gentoo Hardened 3.4.6-r2 p1.6, ssp-3.4.6-1.0, pie-8.7.10) $ uname -a Linux localhost 2.6.28-hardened-r9 #2 SMP Mon Jun 15 07:58:03 EDT 2009 x86_64 Intel(R) Core(TM)2 Duo CPU T5750 @ 2.00GHz GenuineIntel GNU/Linux
I can also compile by selecting x86_64-pc-linux-gnu-3.4.6-hardenednopie. However, either way PAX will kill the process, setting the flags off with paxctl -pmerxs `which qemu` will stop it from being killed by PAX, but a segfault will occur. This doesn't happen if you do run "qemu --help", it only happens while running the VM.
Hmm, you actually can compile and run (the stable) qemu-0.9.0 by selecting "x86_64-pc-linux-gnu-3.4.6-hardenednopie" or a similar gcc 3.x with gcc-config, then removing PAX protection "paxctl -pmerxs `which qemu`". The same thing worked for the latest qemu-0.10.5, except it's segfault mania.
Ok, this was a totally bad idea. There is bugs in softmmu that arise with 0.10.x at least if built with -fPIE, and the build-break if you filter -fPIE is totally unrelated and will be handled in a seperate bug. The -fstack-protect filter is still wrong, but as the current ebuild even tho it looks like it actually do not filter -fstack-protector I do not care about it currently.
