http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57316
--- Comment #3 from Paul H. Hargrove <PHHargrove at lbl dot gov> --- (In reply to Kostya Serebryany from comment #1) > Sorry for the breakages, but we are unable to monitor build failures on old > kernels unless someone sets up a regular testing (build bot) with such kernels > for upstream code. This error is from a private "build bot" I've now got set up to perform daily builds of the gupc branch in SVN (see http://gcc.gnu.org/projects/gupc.html). As changes are merged from the trunk to that branch I will notice any build failures and I report them to the GCC Bugzilla if/when I can reproduce them in the trunk or recent snapshot (eg bug 55989) or in a release (as with this bug). Otherwise they are reported to the GUPC team. I am configuring with --disable-libsanitizer right now, but will remove that when/if this bug is resolved such that I can build again. (In reply to Jakub Jelinek from comment #2) > If you don't have __NR_exit_group, your kernel very likely doesn't have the > rest of NPTL support either (so e.g. __NR_futex), so I'm surprised this is > the only error. This is an old Red Hat "2.4.21-60.ELsmp" kernel that contains various bits that Red Hat backported. So, the unistd.h has __NR_fuxtex but not __NR_exit_group. I can't say for sure that futex works, however, as there is no NPTL version of libpthread on the system. For my own purposes, there is no need to make libsanitizer work on this platform. So, if that is not possible I'd like to see configure probe for each of the syscall numbers (and prctl constants as in bug 55989) and then automatically disable building the sanitizer code if any are missing. I don't like current the build-is-broken-by-default situation.