Kernel KVM virtualization development
 help / color / mirror / Atom feed
From: Andre Przywara <andre.przywara@arm.com>
To: Michael Ellerman <mpe@ellerman.id.au>, Will Deacon <Will.Deacon@arm.com>
Cc: Matt Evans <matt@ozlabs.org>,
	"kvm@vger.kernel.org" <kvm@vger.kernel.org>,
	"kvm-ppc@vger.kernel.org" <kvm-ppc@vger.kernel.org>,
	"kvmarm@lists.cs.columbia.edu" <kvmarm@lists.cs.columbia.edu>
Subject: Re: [PATCH] kvmtool: Makefile: allow overriding CC and LD
Date: Fri, 19 Jun 2015 11:00:34 +0100	[thread overview]
Message-ID: <5583E842.8090402@arm.com> (raw)
In-Reply-To: <1434676494.23771.2.camel@ellerman.id.au>

Hi Michael,

On 19/06/15 02:14, Michael Ellerman wrote:
> On Thu, 2015-06-18 at 16:50 +0100, Andre Przywara wrote:
>> Currently we set CC unconditionally to ${CROSS_COMPILE}gcc, the same
>> for LD.
>> Allow people to override the compiler name by specifying it explicitly
>> on the command line or via the environment.
>> Beside calling a certain compiler binary this allows to pass in
>> options to the compiler, which lets us get rid of the PowerPC
>> overrides in the Makefile. Possible uses:
>> $ make CC="gcc -m64" LD="ld -melf64ppc"
>> (build kvmtool on a PowerPC toolchain defaulting to 32-bit)
>> $ make CC="gcc -m32" LD="ld -melf_i386"
>> (build a 32-bit binary on a multilib-enabled x86-64 compiler)
> 
> 
> I'm not a big fan of that.
> 
> Your examples are all about overriding CFLAGS and LDFLAGS, not CC and LD. So
> if anything you should be allowing that. Adding flags to CC and LD is asking
> for trouble.

Will just disabled overriding CFLAGS and LDFLAGS, I think because
kvmtool inherited some C nastiness from the kernel, which does not
compile with random flags set (CFLAGS=-std=gnu99 was the one the broke it).
Maybe we should revisit that, either fix the code to be more robust to
comply with various standards or document that you should not have
CFLAGS set. Then allow overriding CFLAGS again.

But I thought that overriding CC is common practise - if you want to
select a different compiler, that is. Using a different bitness seems a
lot like a different compiler to me, same with different endianness.
I think I saw quite some examples on the web about using CC="gcc -m32".

I agree that abusing CC to pass optimization options to the compiler is
not good, but for kvmtool's Makefile I don't see how adding flags to CC
would hurt.

Cheers,
Andre.

  reply	other threads:[~2015-06-19 10:00 UTC|newest]

Thread overview: 5+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-06-18 15:50 [PATCH] kvmtool: Makefile: allow overriding CC and LD Andre Przywara
2015-06-19  1:14 ` Michael Ellerman
2015-06-19 10:00   ` Andre Przywara [this message]
2015-06-19  9:59 ` Paolo Bonzini
2015-06-19 10:23   ` Andre Przywara

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=5583E842.8090402@arm.com \
    --to=andre.przywara@arm.com \
    --cc=Will.Deacon@arm.com \
    --cc=kvm-ppc@vger.kernel.org \
    --cc=kvm@vger.kernel.org \
    --cc=kvmarm@lists.cs.columbia.edu \
    --cc=matt@ozlabs.org \
    --cc=mpe@ellerman.id.au \
    /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