Re: Detecting libc in perf (was Re: perf tools build broken after v5.1-rc1)

From: Vineet Gupta
Date: Thu May 02 2019 - 12:56:16 EST

On 4/30/19 8:12 PM, Rich Felker wrote:
>>> What are you trying to achieve? I was just CC'd and I'm missing the
>>> context.
>> Sorry I added you as a subject matter expert but didn't provide enough context.
>> The original issue [1] was perf failing to build on ARC due to perf tools needing
>> a copy of unistd.h but this thread [2] was a small side issue of auto-detecting
>> libc variaint in perf tools where despite uClibc tools, glibc is declared to be
>> detected, due to uClibc's historical hack of defining __GLIBC__. So __GLIBC__ is
>> not sufficient (and probably not the right interface to begin wtih) to ensure glibc.
>> [1]
>> [2]
> I think you misunderstood --


> I'm asking what you're trying to achieve
> by detecting whether the libc is glibc, rather than whether it has
> some particular interface you want to conditionally use. This is a
> major smell and is usually something wrong that shouldn't be done.

Good question indeed. Back in 2015 I initially ran into some quirks due to subtle
libc differences. At the time perf has a fwd ref for strlcpy which exactly
matched glibc but not uClibc. see commit a83d869f300bf91 "(perf tools: Elide
strlcpy warning with uclibc)" or 0215d59b154 "(tools lib: Reinstate strlcpy()
header guard with __UCLIBC__)"

But this still used the libc defined symbol __UCLIBC__ or __GLIBC__

Your question however pertains to perf glibc feature check where perf generates an
alternate symbol HAVE_GLIBC_SUPPORT.

This is dubious as first of all it detects glibc even for uClibc builds.

Even of we were to improve it, there seems to be no users of this symbol.

perf/Makefile.config: CFLAGS += -DHAVE_GLIBC_SUPPORT
perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc)

So I'd propose to remove it !