2 May
2019
2 May
'19
4:55 p.m.
On 4/30/19 8:12 PM, Rich Felker wrote:
I think you misunderstood --
:-)
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] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005676.html
[2] http://lists.infradead.org/pipermail/linux-snps-arc/2019-April/005684.html 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.
$git grep HAVE_GLIBC_SUPPORT
perf/Makefile.config: CFLAGS += -DHAVE_GLIBC_SUPPORT
perf/builtin-version.c: STATUS(HAVE_GLIBC_SUPPORT, glibc)
So I'd propose to remove it !