public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Jiri Olsa <jolsa@redhat.com>
To: Arnaldo Carvalho de Melo <acme@kernel.org>
Cc: "David Carrillo-Cisneros" <davidcc@google.com>,
	"Mark Rutland" <mark.rutland@arm.com>,
	linux-kernel@vger.kernel.org, "Ingo Molnar" <mingo@redhat.com>,
	"Peter Zijlstra" <peterz@infradead.org>,
	"Jiri Olsa" <jolsa@kernel.org>,
	"Alexander Shishkin" <alexander.shishkin@linux.intel.com>,
	"Wang Nan" <wangnan0@huawei.com>, "He Kuang" <hekuang@huawei.com>,
	"Michal Marek" <mmarek@suse.com>,
	"Uwe Kleine-König" <u.kleine-koenig@pengutronix.de>,
	"Stephane Eranian" <eranian@google.com>,
	"Paul Turner" <pjt@google.com>
Subject: Re: [PATCH 3/4] tools lib feature: Do not redefine compiler configuration
Date: Mon, 6 Feb 2017 16:42:13 +0100	[thread overview]
Message-ID: <20170206154213.GA13416@krava> (raw)
In-Reply-To: <20170206133859.GB11283@kernel.org>

On Mon, Feb 06, 2017 at 10:38:59AM -0300, Arnaldo Carvalho de Melo wrote:
> Em Wed, Feb 01, 2017 at 10:38:03PM -0800, David Carrillo-Cisneros escreveu:
> > Feature detection redefines CC, CCX and PKG_CONFIG, making the
> > output of feature detection inconsistent with the actual features
> > available during compilation when the above variables are used.
> > 
> > Fix it by using conditional assignment.
> 
> This one is tricky, the real meaning of that line got lost somewhere,
> its original intent, in commit 8b6eb56a9570 ("tools/perf/build: Add
> 'autodep' functionality, generate feature test dependencies
> automatically") was to just add that "-MD" to whatever definition CC
> had, be it the default one or a value set by the user in the make
> command line.
> 
> At some point someone added that CROSS_COMPILE there, which it should
> have gotten from the default CC definition
> 
> It was here: a8a5cd8b472c ("perf: tools: Fix cross building")
> 
>     perf: tools: Fix cross building
>     
>     Currently the feature-checks Makefile does not inherit $(CC), and calls
>     cc rather than $(CROSS_COMPILE)gcc. Thus the feature checks invoke the
>     native toolchain rather than the cross toolchain, and can identify
>     features as available when they are not. This can break the build
> 
> ----------------------------------
> 
> Mark, do you recall why can't we make tools/perf/Makefile.perf pass the
> definitions of CC, AR and PKG_CONFIG to tools/perf/config/Makefile (now
> tools/build/feature/Makefile) so that the original intent (adding -MD to
> whatever was in CC) can be kept?
> 
> Jiri?

I guess we could remove -MD from the gcc like and add it to the CFLAGS
if we want to keep the CC/CXX lines alone..

jirka

  reply	other threads:[~2017-02-06 15:42 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-02-02  6:38 [PATCH 0/4] Fixes for perf build and feature detection David Carrillo-Cisneros
2017-02-02  6:38 ` [PATCH 1/4] perf tools: pass PYTHON config to " David Carrillo-Cisneros
2017-02-06 13:19   ` Arnaldo Carvalho de Melo
2017-02-06 15:19     ` Namhyung Kim
2017-02-07 19:47   ` Arnaldo Carvalho de Melo
2017-02-08  3:15     ` David Carrillo-Cisneros
2017-02-08  5:28       ` [PATCH v2] tools lib traceevent: Robustify do_generate_dynamic_list_file David Carrillo-Cisneros
2017-02-08 12:44         ` Arnaldo Carvalho de Melo
2017-02-08 13:24           ` Arnaldo Carvalho de Melo
2017-02-09  5:03             ` David Carrillo-Cisneros
2017-02-10  7:47         ` [tip:perf/core] " tip-bot for David Carrillo-Cisneros
2017-02-02  6:38 ` [PATCH 2/4] " David Carrillo-Cisneros
2017-02-06 17:45   ` Arnaldo Carvalho de Melo
2017-02-02  6:38 ` [PATCH 3/4] tools lib feature: Do not redefine compiler configuration David Carrillo-Cisneros
2017-02-06 13:38   ` Arnaldo Carvalho de Melo
2017-02-06 15:42     ` Jiri Olsa [this message]
2017-02-02  6:38 ` [PATCH 4/4] tools include: Fix include path for uapi/asm-generic/mman.h David Carrillo-Cisneros
2017-02-02 12:56   ` Jiri Olsa
2017-02-06 18:25   ` Arnaldo Carvalho de Melo
2017-02-06 20:09     ` David Carrillo-Cisneros
2017-02-02 12:56 ` [PATCH 0/4] Fixes for perf build and feature detection Jiri Olsa

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=20170206154213.GA13416@krava \
    --to=jolsa@redhat.com \
    --cc=acme@kernel.org \
    --cc=alexander.shishkin@linux.intel.com \
    --cc=davidcc@google.com \
    --cc=eranian@google.com \
    --cc=hekuang@huawei.com \
    --cc=jolsa@kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mark.rutland@arm.com \
    --cc=mingo@redhat.com \
    --cc=mmarek@suse.com \
    --cc=peterz@infradead.org \
    --cc=pjt@google.com \
    --cc=u.kleine-koenig@pengutronix.de \
    --cc=wangnan0@huawei.com \
    /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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox