All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ingo Molnar <mingo@kernel.org>
To: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: Josh Poimboeuf <jpoimboe@redhat.com>,
	Ingo Molnar <mingo@redhat.com>,
	x86@kernel.org, linux-kernel@vger.kernel.org,
	Masami Hiramatsu <masami.hiramatsu.pt@hitachi.com>,
	Adrian Hunter <adrian.hunter@intel.com>,
	Michael Ellerman <mpe@ellerman.id.au>,
	Peter Zijlstra <peterz@infradead.org>,
	Thomas Gleixner <tglx@linutronix.de>,
	"H. Peter Anvin" <hpa@zytor.com>
Subject: Re: [PATCH 2/2] objtool: Support CROSS_COMPILE
Date: Thu, 3 Mar 2016 16:10:21 +0100	[thread overview]
Message-ID: <20160303151020.GA11570@gmail.com> (raw)
In-Reply-To: <20160303143843.6eaf80b5@canb.auug.org.au>


* Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Josh,
> 
> On Wed, 2 Mar 2016 21:20:58 -0600 Josh Poimboeuf <jpoimboe@redhat.com> wrote:
> >
> > On Thu, Mar 03, 2016 at 01:43:14PM +1100, Stephen Rothwell wrote:
> > > 
> > > I was wondering if this would be more appropriate in scripts/objtool
> > > since it is used during the building of the kernel.  Or does it have a
> > > wider use?  
> > 
> > Yeah, it was actually in the scripts/ dir in earlier revisions of the
> > patch set, for that very reason.  However, Ingo pointed out that it
> > could be useful beyond the kernel, so we graduated it to a "tool".
> > 
> > > 
> > > We have HOSTCC with its associated HOSTCFLAGS etc ... I am not sure if
> > > that is more appropriate (but it does take care of people using clang).  
> > 
> > The "tools" are almost completely separate from the rest of the kernel.
> > They have their own scaled-down version of kbuild, which doesn't have
> > HOSTCC.
> > 
> > But yeah, we might eventually need to copy some of the host compilation
> > infrastructure from scripts/Makefile.host over to the tools/ side.
> 
> That all sounds sane, thanks.
> 
> I did not add this to linux-next today, but may tomorrow if people
> think it is sensible to do so (for testing on a powerpcle host).  If I
> do, I will just back out to the previous patch if it all goes south (so
> it won't impact on the rest of the tip tree's testing).

I'll add Josh's fixes to -tip ASAP as well, so hopefully soon you can drop all 
linux-next specific patches related to this and it will all work Just Fine (tm).

Sorry about the breakage!

Thanks,

	Ingo

  parent reply	other threads:[~2016-03-03 15:10 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-03-01  1:29 linux-next: build failure after merge of the tip tree Stephen Rothwell
2016-03-01  7:07 ` Ingo Molnar
2016-03-01  7:28   ` Sedat Dilek
2016-03-01  7:39     ` H. Peter Anvin
2016-03-01  8:41       ` Sedat Dilek
2016-03-01  9:45       ` Ingo Molnar
2016-03-01  9:40   ` Stephen Rothwell
2016-03-01 21:54     ` [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used Josh Poimboeuf
2016-03-02  2:27       ` Stephen Rothwell
2016-03-02 21:17         ` Josh Poimboeuf
2016-03-02 22:21           ` Stephen Rothwell
2016-03-03  0:39             ` [PATCH 0/2] objtool: Cross-compilation support Josh Poimboeuf
2016-03-03  0:39               ` [PATCH 1/2] x86/asm/decoder: Use explicitly signed chars Josh Poimboeuf
2016-03-03 16:51                 ` [tip:core/objtool] " tip-bot for Josh Poimboeuf
2016-03-03 19:00                   ` H. Peter Anvin
2016-03-03  0:39               ` [PATCH 2/2] objtool: Support CROSS_COMPILE Josh Poimboeuf
2016-03-03  2:43                 ` Stephen Rothwell
2016-03-03  3:20                   ` Josh Poimboeuf
2016-03-03  3:38                     ` Stephen Rothwell
2016-03-03  3:46                       ` Josh Poimboeuf
2016-03-03 15:10                       ` Ingo Molnar [this message]
2016-03-03 22:59                         ` Stephen Rothwell
2016-03-03 15:23                   ` H. Peter Anvin
2016-03-03 16:52                 ` [tip:core/objtool] " tip-bot for Josh Poimboeuf
2016-03-03  7:31         ` [PATCH] objtool: Disable stack validation when CROSS_COMPILE is used Sedat Dilek
2016-03-03  7:57           ` Stephen Rothwell

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=20160303151020.GA11570@gmail.com \
    --to=mingo@kernel.org \
    --cc=adrian.hunter@intel.com \
    --cc=hpa@zytor.com \
    --cc=jpoimboe@redhat.com \
    --cc=linux-kernel@vger.kernel.org \
    --cc=masami.hiramatsu.pt@hitachi.com \
    --cc=mingo@redhat.com \
    --cc=mpe@ellerman.id.au \
    --cc=peterz@infradead.org \
    --cc=sfr@canb.auug.org.au \
    --cc=tglx@linutronix.de \
    --cc=x86@kernel.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.