From: Namhyung Kim <namhyung.kim@lge.com>
To: David Daney <ddaney.cavm@gmail.com>
Cc: linux-kernel@vger.kernel.org,
David Daney <david.daney@cavium.com>,
Peter Zijlstra <a.p.zijlstra@chello.nl>,
Paul Mackerras <paulus@samba.org>, Ingo Molnar <mingo@elte.hu>,
Arnaldo Carvalho de Melo <acme@ghostprotocols.net>,
Joerg Roedel <joerg.roedel@amd.com>,
namhyung@gmail.com
Subject: Re: [PATCH] perf: Fix broken build by rearranging some #includes
Date: Tue, 17 Jan 2012 16:17:58 +0900 [thread overview]
Message-ID: <4F1520A6.7070908@lge.com> (raw)
In-Reply-To: <1326765685-7686-1-git-send-email-ddaney.cavm@gmail.com>
Hi,
2012-01-17 11:01 AM, David Daney wrote:
> From: David Daney<david.daney@cavium.com>
>
> When building on my Debian/mips system, util/util.c fails to build
> because commit 1aed2671738785e8f5aea663a6fda91aa7ef59b5 (perf kvm: Do
> guest-only counting by default) indirectly includes stdio.h before the
> feature selection in util.h is done. This prevents _GNU_SOURCE in
> util.h from enabling the declaration of getline(), from now second
> inclusion of stdio.h, and the build is broken.
I've experienced similar problem wrt pwrite() last week. The fix was
simply removing ctype.h from inclusion for my case.
>
> There is another breakage in util/evsel.c caused by include ordering,
> but I didn't fully track down the commit that caused it.
>
> Since the #include situation is a little convoluted throughout perf, I
> did the following:
>
> 1) Always include util/util.h before all other include files.
>
> 2) Remove all #define _GNU_SOURCE, as it is already done in util.h.
>
> 3) Remove all #undef _GNU_SOURCE, as they don't do what a naive person
> might expect (or much of anything for that matter) and clutter up
> the source.
>
> 4) #include ctype.h in util.h, so that ctype things have uniform
> definitions throughout perf.
Among other things, ctype.h isn't needed at all since util.h redefines
all of ctype macros anyway. I've posted a patch which removes ctype.h
inclusions as Ingo's suggestion.
https://lkml.org/lkml/2012/1/16/510
Thanks,
Namhyung Kim
next prev parent reply other threads:[~2012-01-17 7:18 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2012-01-17 2:01 [PATCH] perf: Fix broken build by rearranging some #includes David Daney
2012-01-17 7:17 ` Namhyung Kim [this message]
2012-01-17 7:25 ` Namhyung Kim
2012-01-17 18:49 ` David Daney
2012-01-17 7:25 ` Namhyung Kim
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=4F1520A6.7070908@lge.com \
--to=namhyung.kim@lge.com \
--cc=a.p.zijlstra@chello.nl \
--cc=acme@ghostprotocols.net \
--cc=david.daney@cavium.com \
--cc=ddaney.cavm@gmail.com \
--cc=joerg.roedel@amd.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=namhyung@gmail.com \
--cc=paulus@samba.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.