[Bug sanitizer/61021] New: [4.9 regression] libsanitizer fails to build with old glibc

[Bug sanitizer/61021] New: [4.9 regression] libsanitizer fails to build with old glibc

[sandra at codesourcery dot com]

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.

[Bug sanitizer/61021] [4.9 regression] libsanitizer fails to build with old glibc

[kcc at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021

--- Comment #1 from Kostya Serebryany <kcc at gcc dot gnu.org> ---
Please send the patch to llvm-commits, we'll review it and apply it upstream
(We may not be able to do so before ~ May 5).
Then you can either wait for the next merge (we planned it for ~ mid May, but
it may take quite some time), or send it directly to gcc-patches

>> the minimum kernel/glibc requirements for libsanitizer need to be documented
>> and enforced by the configure scripts if possible.
I thought this was done. Jakub?

[Bug sanitizer/61021] [4.9 regression] libsanitizer fails to build with old glibc

[jakub at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
I have been only testing back to RHEL5, which has glibc 2.5 and glibc 2.5 has
PTRACE_{S,G}ETSIGINFO.
Given that there is a conditional already for PTRACE_{S,G}ETREGSET which has
been added later than this one, I'd say the patch is better than adding the
stuff to the include/ headers GCC libsanitizer owns.

[Bug sanitizer/61021] [4.9 regression] libsanitizer fails to build with old glibc

[sandra at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021

--- Comment #3 from Sandra Loosemore <sandra at codesourcery dot com> ---
Patch sent to llvm-commits.

For now I can unblock my work by applying the patch locally, but this isn't
something we'd want to carry around permanently and have to apply to future
versions of GCC, especially if it is the wrong way to solve the problem.

[Bug sanitizer/61021] [4.9/4.10 regression] libsanitizer fails to build with old glibc

[rguenth at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
           Priority|P3                          |P2
   Target Milestone|---                         |4.9.1
            Summary|[4.9 regression]            |[4.9/4.10 regression]
                   |libsanitizer fails to build |libsanitizer fails to build
                   |with old glibc              |with old glibc

[Bug sanitizer/61021] [4.9/4.10 regression] libsanitizer fails to build with old glibc

[sandra at codesourcery dot com]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021

--- Comment #4 from Sandra Loosemore <sandra at codesourcery dot com> ---
Patch has been committed to llvm libsanitizer trunk:

http://llvm.org/viewvc/llvm-project?view=revision&revision=208066

[Bug sanitizer/61021] [4.9/4.10 regression] libsanitizer fails to build with old glibc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.1                       |4.9.2

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.1 has been released.

[Bug sanitizer/61021] [4.9/5 regression] libsanitizer fails to build with old glibc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.9.2                       |4.9.3

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 4.9.2 has been released.

[Bug sanitizer/61021] [4.9/5 regression] libsanitizer fails to build with old glibc

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61021

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Thus we should have this already in GCC trunk.  Does it still fail to build
there?