30 Apr
2019
30 Apr
'19
3:53 p.m.
On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
Ok, I'll improve that, I think
it just tries to detect a libc, yeah,
see:
[acme@quaco linux]$ cat tools/build/feature/test-glibc.c
// SPDX-License-Identifier: GPL-2.0
#include <stdlib.h>
#if !defined(__UCLIBC__)
#include <gnu/libc-version.h>
#else
#define XSTR(s) STR(s)
#define STR(s) #s
#endif
int main(void)
{
#if !defined(__UCLIBC__)
const char *version = gnu_get_libc_version();
#else
const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
#endif
return (long)version;
}
[acme@quaco linux]$
[perfbuilder@59ca4b424ded /]$ grep __GLIBC__
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:
The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define __GLIBC__ 2
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h: ((__GLIBC__
<< 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
[perfbuilder@59ca4b424ded /]$
Isn't that part of uClibc?
Right you are. Per the big fat comment right above that code, this gross hack in
uclibc is unavoidable as applications tend to rely on that define.
So a better fix would be to check for various !GLIBC libs explicitly.
#ifdef __UCLIBC__
#elseif defined __MUSL__
...
Not pretty from app usage pov, but that seems to be the only sane way of doing it.
-Vineet
Auto-detecting system features:
... dwarf: [ OFF ]
... dwarf_getlocations: [ OFF ]
... glibc: [ on ]
Not related to current issue, this run
uses a uClibc toolchain and yet it is
detecting glibc - doesn't seem right to me. 
30 Apr
30 Apr
5:04 p.m.
On Tue, Apr 30, 2019 at 03:53:18PM +0000, Vineet Gupta wrote:
On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo wrote:
Ok, I'll improve that, I think
it just tries to detect a libc, yeah,
see:
[acme@quaco linux]$ cat tools/build/feature/test-glibc.c
// SPDX-License-Identifier: GPL-2.0
#include <stdlib.h>
#if !defined(__UCLIBC__)
#include <gnu/libc-version.h>
#else
#define XSTR(s) STR(s)
#define STR(s) #s
#endif
int main(void)
{
#if !defined(__UCLIBC__)
const char *version = gnu_get_libc_version();
#else
const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
#endif
return (long)version;
}
[acme@quaco linux]$
[perfbuilder@59ca4b424ded /]$ grep __GLIBC__
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:
The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define __GLIBC__ 2
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h: ((__GLIBC__
<< 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
[perfbuilder@59ca4b424ded /]$
Isn't that part of uClibc?
Right you are. Per the big fat comment right above that code, this gross hack in
uclibc is unavoidable as applications tend to rely on that define.
So a better fix would be to check for various !GLIBC libs explicitly.
#ifdef __UCLIBC__
#elseif defined __MUSL__
....
Not pretty from app usage pov, but that seems to be the only sane way of doing it.
What are you trying to achieve? I was just CC'd and I'm missing the
context.
Rich
Auto-detecting system features:
... dwarf: [ OFF ]
... dwarf_getlocations: [ OFF ]
... glibc: [ on ]
Not related to current issue, this run
uses a uClibc toolchain and yet it is
detecting glibc - doesn't seem right to me.
5:13 p.m.
On 4/30/19 10:04 AM, Rich Felker wrote:
On Tue, Apr 30, 2019 at 03:53:18PM +0000, Vineet Gupta
wrote:
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
On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo
wrote:
Right you are. Per the big fat comment right above that code, this gross hack in
uclibc is unavoidable as applications tend to rely on that define.
So a better fix would be to check for various !GLIBC libs explicitly.
#ifdef __UCLIBC__
#elseif defined __MUSL__
....
Not pretty from app usage pov, but that seems to be the only sane way of doing it.
What are you trying to achieve? I was just CC'd and I'm missing the
context. >
Auto-detecting system features:
> ... dwarf: [ OFF ]
> ... dwarf_getlocations: [ OFF ]
> ... glibc: [ on ]
Not related to current issue, this run uses a uClibc toolchain and yet it is
detecting glibc - doesn't seem right to me.
Ok, I'll improve that, I think
it just tries to detect a libc, yeah,
see:
[acme@quaco linux]$ cat tools/build/feature/test-glibc.c
// SPDX-License-Identifier: GPL-2.0
#include <stdlib.h>
#if !defined(__UCLIBC__)
#include <gnu/libc-version.h>
#else
#define XSTR(s) STR(s)
#define STR(s) #s
#endif
int main(void)
{
#if !defined(__UCLIBC__)
const char *version = gnu_get_libc_version();
#else
const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
#endif
return (long)version;
}
[acme@quaco linux]$
[perfbuilder@59ca4b424ded /]$ grep __GLIBC__
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:
The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define __GLIBC__ 2
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h: ((__GLIBC__
<< 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
[perfbuilder@59ca4b424ded /]$
Isn't that part of uClibc?
1 May
1 May
3:12 a.m.
On Tue, Apr 30, 2019 at 10:13:40AM -0700, Vineet Gupta wrote:
On 4/30/19 10:04 AM, Rich Felker wrote:
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.
Rich
On Tue, Apr 30, 2019 at 03:53:18PM +0000, Vineet
Gupta wrote:
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 On 4/29/19 6:18 PM, Arnaldo Carvalho de Melo
wrote:
What are you trying to achieve? I was just CC'd and I'm missing the
context. >> Auto-detecting system features:
>> ... dwarf: [ OFF ]
>> ... dwarf_getlocations: [ OFF ]
>> ... glibc: [ on ]
> Not related to current issue, this run uses a uClibc toolchain and yet it is
> detecting glibc - doesn't seem right to me.
Ok, I'll improve that, I think it just tries to detect a libc, yeah,
see:
[acme@quaco linux]$ cat tools/build/feature/test-glibc.c
// SPDX-License-Identifier: GPL-2.0
#include <stdlib.h>
#if !defined(__UCLIBC__)
#include <gnu/libc-version.h>
#else
#define XSTR(s) STR(s)
#define STR(s) #s
#endif
int main(void)
{
#if !defined(__UCLIBC__)
const char *version = gnu_get_libc_version();
#else
const char *version = XSTR(__GLIBC__) "." XSTR(__GLIBC_MINOR__);
#endif
return (long)version;
}
[acme@quaco linux]$
[perfbuilder@59ca4b424ded /]$ grep __GLIBC__
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/*.h
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:
The macros `__GNU_LIBRARY__', `__GLIBC__', and `__GLIBC_MINOR__' are
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h:#define __GLIBC__ 2
/arc_gnu_2017.09-rc2_prebuilt_uclibc_le_arc700_linux_install/arc-snps-linux-uclibc/sysroot/usr/include/features.h: ((__GLIBC__
<< 16) + __GLIBC_MINOR__ >= ((maj) << 16) + (min))
[perfbuilder@59ca4b424ded /]$
Isn't that part of uClibc?
Right you are. Per the big fat comment right above that code, this gross hack in
uclibc is unavoidable as applications tend to rely on that define.
So a better fix would be to check for various !GLIBC libs explicitly.
#ifdef __UCLIBC__
#elseif defined __MUSL__
....
Not pretty from app usage pov, but that seems to be the only sane way of doing it.
2 May
2 May
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 !
1820
days inactive
1822
days old
4 comments
2 participants
participants (2)
-
Rich Felker -
Vineet Gupta