http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021
Bug ID: 61021
Summary: [4.9 regression] libsanitizer fails to build with old
glibc
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: sanitizer
Assignee: unassigned at gcc dot gnu.org
Reporter: sandra at codesourcery dot com
CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
jakub at gcc dot gnu.org, kcc at gcc dot gnu.org
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Created attachment 32718
--> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32718&action=edit
patch to conditionalize references
We build a native i686-pc-linux-gnu toolchain against a relatively ancient
sysroot (glibc 2.4) so that the resulting binaries will work on a variety of
older GNU/Linux distros. GCC 4.9 is now failing to build this configuration
due to references to undefined symbols PTRACE_GETSIGINFO and PTRACE_SETSIGINFO
in libsanitizer.
I see that in other issues the maintainers have suggested disabling
libsanitizer in cases where the kernel/glibc version is too old for it to
build, but this looks like a regression to me: it used to work in GCC 4.8. The
attached patch is sufficient to get it to at least build again, and it's
consistent with the way PTRACE_GETREGSET and PTRACE_SETREGSET are being
handled.
libsanitizer/README.gcc says "Trivial and urgent fixes (portability, build
fixes, etc.) may go directly to the GCC tree." Does this one qualify under
that policy? If not, I'll have to echo what has already been suggested
elsewhere: the minimum kernel/glibc requirements for libsanitizer need to be
documented and enforced by the configure scripts if possible.
