This entry is more of an observational report than an actual bug. The build machine uses a grsec kernel that enforces stack and mmap base address randomization (CONFIG_PAX_RANDMMAP && CONFIG_PAX_PT_PAX_FLAGS && !CONFIG_PAX_SOFTMODE). The Yocto build is then started under a Docker session. All goes well until qemu-x86_64 is invoked to run target programs, where it hangs in a tight CPU loop. paxctl is used to fix this situation: [Stop the build, paxctl refuse to work on files that are in use] paxctl -c .../qemu-x86_64 paxctl -r .../qemu-x86_64 [Continue the build] Other grsec build machine observations: Trusted Path Execution (CONFIG_GRKERNSEC_TPE) interferes with cdrecord-native build because it runs tests under world writeable directories. W/A: Temporarily set /proc/sys/kernel/grsecurity/tpe to 0. Likewise for these if the build is run under docker /proc/sys/kernel/grsecurity/chroot_deny_chmod /proc/sys/kernel/grsecurity/chroot_deny_fchdir
Additionally, qt4-native also needs -no-pch to avoid ICE on the docker compiler. Cause is unknown. Docker container is running Debian Jessie with gcc version 4.9.2 (Debian 4.9.2-10).
Thanks for the report and the steps needed to work-around the problem. There was a short discussion about this and while it's tempting to fix the problem, no one knew of a commonly used distro that enabled grsec so it didn't seem like a valid bug or one that would get fixed. It would be good to report the problem to qemu upstream maintainers. I added a link to this defect in the wiki: https://wiki.yoctoproject.org/wiki/Technical_FAQ#Building_on_a_system_with_a_GRSec_kernel_doesn.27t_work_well.2C_is_that_supported.3F and I'm closing the defect as won't fix.