From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f44.google.com (mail-wg0-f44.google.com [74.125.82.44]) by dpdk.org (Postfix) with ESMTP id C5EDA7F00 for ; Wed, 17 Dec 2014 15:02:25 +0100 (CET) Received: by mail-wg0-f44.google.com with SMTP id b13so20305587wgh.17 for ; Wed, 17 Dec 2014 06:02:25 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=1SAaKE/CkCoOWYccvrgtAufqdbPZhACK8YsBzPKoItU=; b=GCNEOL4JJe1gWzpJxvf4FiHkDra6tdKQGtFIUlpmxFEJEGl/kAjkqyOa5lB0VuwrSR 53Cn/Satcw0dVKtbZtXtWBMueqiTljQSoVFIs0Nhw9e3/sBFjJskYhSS9JhZTIuqx2cx wtTy71q7tA33RxCS+NceOUx3Eh+FyzFdZ6ELhXQhgFpHdixek4bvEwelQgKu2BhL+gS8 Y/yaNbX+i7WJnNOpC32NaTy1uCYd33aFOPEVbfMDh0Hoo9yAqm+bx65QlmFWDRCjE6+0 1I9fusCCuUjUWP5F45siy+gBBi5lJW5nBPCv0UhM/JfhT8Gb39cZsxU6MJxyGYYYYp+k tYDw== X-Gm-Message-State: ALoCoQmuvTxG6FP7Xr8xu5t1XtHs2GG9IjYKmQcJviV+cQCDbqED4iUAlgcaIRvaeP5135npVqDr X-Received: by 10.180.104.9 with SMTP id ga9mr15125828wib.9.1418824945574; Wed, 17 Dec 2014 06:02:25 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id be2sm3578892wjb.38.2014.12.17.06.02.24 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Dec 2014 06:02:24 -0800 (PST) From: Thomas Monjalon To: "Gonzalez Monroy, Sergio" Date: Wed, 17 Dec 2014 15:01:59 +0100 Message-ID: <3025851.uNGPVxDmSR@xps13> Organization: 6WIND User-Agent: KMail/4.14.3 (Linux/3.17.4-1-ARCH; KDE/4.14.3; x86_64; ; ) In-Reply-To: <91383E96CE459D47BCE92EFBF5CE73B004F0B593@IRSMSX107.ger.corp.intel.com> References: <1414078550-692-1-git-send-email-sergio.gonzalez.monroy@intel.com> <1505130.0FLpEfacGg@xps13> <91383E96CE459D47BCE92EFBF5CE73B004F0B593@IRSMSX107.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH v2] mk: link combined shared lib using CC X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Dec 2014 14:02:25 -0000 2014-12-17 10:41, Gonzalez Monroy, Sergio: > > From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com] > > 2014-12-16 19:48, Thomas Monjalon: > > > 2014-10-28 15:48, Sergio Gonzalez Monroy: > > > > Fix: link combined shared lib using CC if LINK_USING_CC is enabled. > > > > > > > > Signed-off-by: Sergio Gonzalez Monroy > > > > --- > > > > mk/rte.lib.mk | 1 - > > > > mk/rte.sharelib.mk | 12 +++++++++++- > > > [...] > > > > --- a/mk/rte.lib.mk > > > > +++ b/mk/rte.lib.mk > > > > @@ -63,7 +63,6 @@ ifeq ($(LINK_USING_CC),1) > > > > # Override the definition of LD here, since we're linking with CC > > > > LD := $(CC) > > > > LD_MULDEFS := $(call linkerprefix,-z$(comma)muldefs) > > > > -CPU_LDFLAGS := $(call linkerprefix,$(CPU_LDFLAGS)) > > > > endif > > > > > > Why are you removing this line? > > > Hi Thomas, > > Basically the problem is when CPU_LDFLAGS has a value, which in the > currently only happens if we set CPU_LDFLAGS in the command line or > build i686 (setting CPU_LDFLAGS=-melf_i386). > In those cases, given the way the makefiles are being included, These 2 files don't include each other. rte.sharelib.mk is included only in lib/Makefile and rte.lib.mk is included in each lib Makefile. I think the problem is not about how the files are included but how this variable is exported. CPU_LDFLAGS is modified in lib/Makefile via rte.sharelib.mk, then exported (see mk/arch/*/rte.vars.mk) then modified again in libs via rte.lib.mk. > CPU_LDFLAGS is being 'linkerprefixed' twice, resulting in build error. > Removing that line avoided the second linker prefix of the CPU_LDFLAGS > (note that we reset the original var instead of using a different var name). > > There probably is a better way but I could not see an straightforward fix for it. I suggest 2 possible fixes: - do not export this variable (why is it exported?) - or do not override the variable, i.e. use a different variable for prefixing > I planned to improve the current build system (already sent an RFC) > and was waiting until 1.8 release to resume the work on it. I agree we should work on improvements after 1.8. > > If it's really needed, it could be another patch. [...] > > > > Applied without the change to rte.lib.mk. It definitely deserves another patch with a proper fix. -- Thomas