https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61538
--- Comment #12 from Joshua Kinard <kumba at gentoo dot org> --- So I discovered the presence of the --disable-linux-futex configure flag, rebuilt gcc-4.9.0 with it, and tested my conftest.c testcase, and can confirm that the resulting binary no longer hangs on a futex syscall. It still calls futex twice somewhere in the call chain, but that's probably expected behavior or a different library (pthreads?): set_tid_address(0x77256068) = 10805 set_robust_list(0x77256070, 12) = 0 futex(0x7fcb46b8, FUTEX_WAKE_PRIVATE, 1) = 0 futex(0x7fcb46b8, FUTEX_WAIT_BITSET_PRIVATE|FUTEX_CLOCK_REALTIME, 1, NULL, 0) = -1 EINVAL (Invalid argument) rt_sigaction(SIGRT_0, {0x8, [], SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|0x7205b94}, NULL, 16) = 0 rt_sigaction(SIGRT_1, {0x10000008, [], SA_RESTART|SA_INTERRUPT|SA_NODEFER|SA_SIGINFO|0x7205a34}, NULL, 16) = 0 rt_sigprocmask(SIG_UNBLOCK, [RT_0 RT_1], NULL, 16) = 0 getrlimit(RLIMIT_STACK, {rlim_cur=8192*1024, rlim_max=2147483647}) = 0 futex(0x771fb9a0, FUTEX_WAKE_PRIVATE, 2147483647) = 0 futex(0x771fb9a4, FUTEX_WAKE_PRIVATE, 2147483647) = 0 exit_group(0) = ? +++ exited with 0 +++ So, not the ideal solution, as I assume under a Linux kernel, there is some advantage to using the futex syscall within gcc, but I don't know how that will affect things. I'll try to compile glibc-2.19 with gcc-4.9.0 and see if the 'sln' static binary also hangs with this change.