From: acme@redhat.com (Arnaldo Carvalho de Melo)
To: linux-snps-arc@lists.infradead.org
Subject: [PATCH] tools lib: Reinstate strlcpy() header guard with __UCLIBC__
Date: Thu, 18 Aug 2016 11:07:22 -0300 [thread overview]
Message-ID: <20160818140722.GC16916@redhat.com> (raw)
In-Reply-To: <1471464050-18044-1-git-send-email-vgupta@synopsys.com>
Em Wed, Aug 17, 2016 at 01:00:50PM -0700, Vineet Gupta escreveu:
> perf tools build in recent kernels spews splat when cross compiling with uClibc
>
> | CC util/alias.o
> | In file included from tools/perf/util/../ui/../util/cache.h:8:0,
> | from tools/perf/util/../ui/helpline.h:7,
> | from tools/perf/util/debug.h:8,
> | from arch/../util/cpumap.h:9,
> | from arch/../util/env.h:5,
> | from arch/common.h:4,
> | from arch/common.c:3:
> | tools/include/linux/string.h:12:15: warning: redundant redeclaration of ?strlcpy? [-Wredundant-decls]
> | extern size_t strlcpy(char *dest, const char *src, size_t size);
> ^
> This is after commit 61a6445e463a31 ("tools lib: Guard the strlcpy() header with
> __GLIBC__"). While the commit was right in theory, issue is uClibc also
> defines __GLIBC__ for application headers.
>
> Instead of reverting the commit, manually revert with some addeed commentary to
> same effect.
Well, you can't revert it, as this will make it break elsewhere. So
please check if
#if defined(__GLIBC__) && !defined(__UCLIBC__)
suits uclibc.
Are you aware of any readily available tarball or docker image that has
a uclibc based devel env that I could grab? I'd add it to my build setup
to make sure I (and my downstreamers) don't break uclibc environments in
the future.
- Arnaldo
> Cc: Adrian Hunter <adrian.hunter at intel.com>
> Cc: Alexey Brodkin <Alexey.Brodkin at synopsys.com>
> Cc: David Ahern <dsahern at gmail.com>
> Cc: Jiri Olsa <jolsa at kernel.org>
> Cc: Namhyung Kim <namhyung at kernel.org>
> Cc: Wang Nan <wangnan0 at huawei.com>
> Cc: Petri Gynther <pgynther at google.com>
> Cc: Peter Zijlstra (Intel) <peterz at infradead.org>
> Signed-off-by: Vineet Gupta <vgupta at synopsys.com>
> ---
> tools/include/linux/string.h | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/include/linux/string.h b/tools/include/linux/string.h
> index b96879477311..5a9e30334ffa 100644
> --- a/tools/include/linux/string.h
> +++ b/tools/include/linux/string.h
> @@ -8,7 +8,12 @@ void *memdup(const void *src, size_t len);
>
> int strtobool(const char *s, bool *res);
>
> -#ifdef __GLIBC__
> +/*
> + * Ideally instead of blacklisting libs which define this already (uclibc,
> + * musl..), we could whitelist libs which reuire it (glibc). However uClibc
> + * also defines __GLIBC__ for user application headers
> + */
> +#ifndef __UCLIBC__
> extern size_t strlcpy(char *dest, const char *src, size_t size);
> #endif
>
> --
> 2.7.4
WARNING: multiple messages have this Message-ID (diff)
From: Arnaldo Carvalho de Melo <acme@redhat.com>
To: Vineet Gupta <Vineet.Gupta1@synopsys.com>
Cc: linux-kernel@vger.kernel.org, linux-snps-arc@lists.infradead.org,
osh Poimboeuf <jpoimboe@redhat.com>,
Adrian Hunter <adrian.hunter@intel.com>,
Alexey Brodkin <Alexey.Brodkin@synopsys.com>,
David Ahern <dsahern@gmail.com>, Jiri Olsa <jolsa@kernel.org>,
Namhyung Kim <namhyung@kernel.org>,
Wang Nan <wangnan0@huawei.com>,
Petri Gynther <pgynther@google.com>,
Peter Zijlstra <peterz@infradead.org>,
acme@kernel.org
Subject: Re: [PATCH] tools lib: Reinstate strlcpy() header guard with __UCLIBC__
Date: Thu, 18 Aug 2016 11:07:22 -0300 [thread overview]
Message-ID: <20160818140722.GC16916@redhat.com> (raw)
In-Reply-To: <1471464050-18044-1-git-send-email-vgupta@synopsys.com>
Em Wed, Aug 17, 2016 at 01:00:50PM -0700, Vineet Gupta escreveu:
> perf tools build in recent kernels spews splat when cross compiling with uClibc
>
> | CC util/alias.o
> | In file included from tools/perf/util/../ui/../util/cache.h:8:0,
> | from tools/perf/util/../ui/helpline.h:7,
> | from tools/perf/util/debug.h:8,
> | from arch/../util/cpumap.h:9,
> | from arch/../util/env.h:5,
> | from arch/common.h:4,
> | from arch/common.c:3:
> | tools/include/linux/string.h:12:15: warning: redundant redeclaration of ‘strlcpy’ [-Wredundant-decls]
> | extern size_t strlcpy(char *dest, const char *src, size_t size);
> ^
> This is after commit 61a6445e463a31 ("tools lib: Guard the strlcpy() header with
> __GLIBC__"). While the commit was right in theory, issue is uClibc also
> defines __GLIBC__ for application headers.
>
> Instead of reverting the commit, manually revert with some addeed commentary to
> same effect.
Well, you can't revert it, as this will make it break elsewhere. So
please check if
#if defined(__GLIBC__) && !defined(__UCLIBC__)
suits uclibc.
Are you aware of any readily available tarball or docker image that has
a uclibc based devel env that I could grab? I'd add it to my build setup
to make sure I (and my downstreamers) don't break uclibc environments in
the future.
- Arnaldo
> Cc: Adrian Hunter <adrian.hunter@intel.com>
> Cc: Alexey Brodkin <Alexey.Brodkin@synopsys.com>
> Cc: David Ahern <dsahern@gmail.com>
> Cc: Jiri Olsa <jolsa@kernel.org>
> Cc: Namhyung Kim <namhyung@kernel.org>
> Cc: Wang Nan <wangnan0@huawei.com>
> Cc: Petri Gynther <pgynther@google.com>
> Cc: Peter Zijlstra (Intel) <peterz@infradead.org>
> Signed-off-by: Vineet Gupta <vgupta@synopsys.com>
> ---
> tools/include/linux/string.h | 7 ++++++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/tools/include/linux/string.h b/tools/include/linux/string.h
> index b96879477311..5a9e30334ffa 100644
> --- a/tools/include/linux/string.h
> +++ b/tools/include/linux/string.h
> @@ -8,7 +8,12 @@ void *memdup(const void *src, size_t len);
>
> int strtobool(const char *s, bool *res);
>
> -#ifdef __GLIBC__
> +/*
> + * Ideally instead of blacklisting libs which define this already (uclibc,
> + * musl..), we could whitelist libs which reuire it (glibc). However uClibc
> + * also defines __GLIBC__ for user application headers
> + */
> +#ifndef __UCLIBC__
> extern size_t strlcpy(char *dest, const char *src, size_t size);
> #endif
>
> --
> 2.7.4
next prev parent reply other threads:[~2016-08-18 14:07 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-08-17 20:00 [PATCH] tools lib: Reinstate strlcpy() header guard with __UCLIBC__ Vineet Gupta
2016-08-17 20:00 ` Vineet Gupta
2016-08-18 14:07 ` Arnaldo Carvalho de Melo [this message]
2016-08-18 14:07 ` Arnaldo Carvalho de Melo
2016-08-18 16:03 ` Vineet Gupta
2016-08-18 16:03 ` Vineet Gupta
2016-08-18 16:17 ` Arnaldo Carvalho de Melo
2016-08-18 16:17 ` Arnaldo Carvalho de Melo
2016-08-19 14:22 ` Arnaldo Carvalho de Melo
2016-08-19 14:22 ` Arnaldo Carvalho de Melo
2016-08-19 18:01 ` Vineet Gupta
2016-08-19 18:01 ` Vineet Gupta
2016-08-19 19:23 ` Arnaldo Carvalho de Melo
2016-08-19 19:23 ` Arnaldo Carvalho de Melo
2016-08-19 20:09 ` Vineet Gupta
2016-08-19 20:09 ` Vineet Gupta
2016-08-19 21:10 ` Arnaldo Carvalho de Melo
2016-08-19 21:10 ` Arnaldo Carvalho de Melo
2016-08-19 21:27 ` Vineet Gupta
2016-08-19 21:27 ` Vineet Gupta
2016-08-19 21:42 ` Arnaldo Carvalho de Melo
2016-08-19 21:42 ` Arnaldo Carvalho de Melo
2016-08-19 23:02 ` Arnaldo Carvalho de Melo
2016-08-19 23:02 ` Arnaldo Carvalho de Melo
2016-08-22 18:01 ` Alexey Brodkin
2016-08-22 18:01 ` Alexey Brodkin
2016-08-22 18:08 ` Arnaldo Carvalho de Melo
2016-08-22 18:08 ` Arnaldo Carvalho de Melo
2016-08-18 16:28 ` [PATCH v2] " Vineet Gupta
2016-08-18 16:28 ` Vineet Gupta
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20160818140722.GC16916@redhat.com \
--to=acme@redhat.com \
--cc=linux-snps-arc@lists.infradead.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.