From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S1755445AbcCRRQ3 (ORCPT ); Fri, 18 Mar 2016 13:16:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:59932 "EHLO mx1.redhat.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754870AbcCRRQ0 (ORCPT ); Fri, 18 Mar 2016 13:16:26 -0400 Date: Fri, 18 Mar 2016 12:16:23 -0500 From: Josh Poimboeuf To: Arnaldo Carvalho de Melo Cc: Lucas Stach , Jiri Olsa , linux-kernel@vger.kernel.org, kernel@pengutronix.de, patchwork-lst@pengutronix.de, Wang Nan , acme@kernel.org Subject: Re: [PATCH] tools lib api: respect CROSS_COMPILE for the linker Message-ID: <20160318171623.mih7ozxyinn33ads@treble.redhat.com> References: <1458235670-27341-1-git-send-email-l.stach@pengutronix.de> <20160318162547.GA2701@redhat.com> <20160318163815.qe7f7cwzis4riwnj@treble.redhat.com> <20160318164522.GB2701@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20160318164522.GB2701@redhat.com> User-Agent: Mutt/1.5.23.1 (2014-03-12) Sender: linux-kernel-owner@vger.kernel.org List-ID: X-Mailing-List: linux-kernel@vger.kernel.org On Fri, Mar 18, 2016 at 01:45:22PM -0300, Arnaldo Carvalho de Melo wrote: > Em Fri, Mar 18, 2016 at 11:38:15AM -0500, Josh Poimboeuf escreveu: > > On Fri, Mar 18, 2016 at 01:25:47PM -0300, Arnaldo Carvalho de Melo wrote: > > > Em Thu, Mar 17, 2016 at 06:27:50PM +0100, Lucas Stach escreveu: > > > > This fixes cross compilation of libapi. > > > > > > Humm, I guess that tools/lib/subcmd/Makefile has the same problem? And > > > there are also other cases where LD is not being set with CROSS_COMPILE, > > > Jiri, is there something else at play here? > > > > > > /me needs to cross compile all this code... > > > > Yeah, I already fixed the libsubcmd issue with commit c1d45c3abd49 in > > tip/core/objtool. (Sorry, I probably should have CC'ed you and Jiri.) > > Not a problem, it will all get merged eventually, but I noticed this: > > -CC = $(CROSS_COMPILE)gcc > -AR = $(CROSS_COMPILE)ar > +CC ?= $(CROSS_COMPILE)gcc > +LD ?= $(CROSS_COMPILE)ld > +AR ?= $(CROSS_COMPILE)ar > > This is how you fixed it, which is different from what other places do > for cross compiling, for instance, this is how tools/lib/bpf/Makefile > does (and it isn't setting LD as well): > > # Allow setting CC and AR, or setting CROSS_COMPILE as a prefix. > $(call allow-override,CC,$(CROSS_COMPILE)gcc) > $(call allow-override,AR,$(CROSS_COMPILE)ar) > > Which is different from what the kernel does in its main Makefile: > > # Make variables (CC, etc...) > AS = $(CROSS_COMPILE)as > LD = $(CROSS_COMPILE)ld > CC = $(CROSS_COMPILE)gcc > > I wonder if we could settle in one of these styles or if there is really > a reason to be creative :-) > > Better, all this could go to tools/scripts/Makefile.include? Yeah, I agree that it would be good to come up with a common and consistent approach tools-wide if possible. The reason I used '?=' is because objtool needs to be built with the host compiler, and the tools kbuild doesn't have hostprogs and HOSTCC. So I and overrode the CC variable. From tools/objtool/Makefile: # always use the host compiler CC = gcc LD = ld AR = ar So the 'CC ?= $(CROSS_COMPILE)gcc' in tools/lib/subcmd/Makefile allows the objtool Makefile to override the cross-compilation and use the host compiler instead. I _think_ 'allow-override' would also work, because the objtool Makefile exports the CC/LD/AR variables to the environment before descending into the subcmd directory. And 'allow-override' seems to allow overriding those variables if they were set in the environment. So 'allow-override' would probably be a good option. -- Josh