From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <thomas.monjalon@6wind.com> Received: from mail-wi0-f169.google.com (mail-wi0-f169.google.com [209.85.212.169]) by dpdk.org (Postfix) with ESMTP id C8B127F07 for <dev@dpdk.org>; Wed, 17 Dec 2014 19:50:05 +0100 (CET) Received: by mail-wi0-f169.google.com with SMTP id r20so17980623wiv.4 for <dev@dpdk.org>; Wed, 17 Dec 2014 10:50:05 -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=/A0r1vl+2eO0Zuqm3Topdvm85GZThtRIofNdeM/Ek4I=; b=VpL48gP9y326DBOVtWl2WfXRM3avSrU2EpE9zjWHpwuJDTCTzvfjdHrr3FA4tTnE+g 9HmfU6ouwW0zvY9nUfNmTG9qXogVPWwpR8KB5YoBNqBZozSCQzOnD98rAhysOUbVbZPW 5hfYOlwkJ1Yh8BdM8K+qPR4mYA+hD7qbx5xTHkDGkobZgO8CDTTDLBTn+t09Xamfc4UR w18IKb+lsu4Hf37nyy4crx9roy+Ca6NxtDB2FigZO8H7OGT7303978U2kQhqLoErhvJ0 ThD3ul7QKxrVRGWOT6Llx6MCT2OWQItXCfBRPK+FPjioEirdx/YXmvT25GGS/vN6ika6 xjxA== X-Gm-Message-State: ALoCoQn6OOETlWeIQip0U6KCQQADYL5O7BjSIOn7UMiAf95AM3O7XBMwnjQlnY4vlmhWZ65JIMa/ X-Received: by 10.180.96.33 with SMTP id dp1mr17277794wib.13.1418842205501; Wed, 17 Dec 2014 10:50:05 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id l9sm21952208wic.21.2014.12.17.10.50.03 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 17 Dec 2014 10:50:04 -0800 (PST) From: Thomas Monjalon <thomas.monjalon@6wind.com> To: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com> Date: Wed, 17 Dec 2014 19:49:38 +0100 Message-ID: <2594499.JbYxbdnDqd@xps13> Organization: 6WIND User-Agent: KMail/4.14.3 (Linux/3.17.4-1-ARCH; KDE/4.14.3; x86_64; ; ) In-Reply-To: <3025851.uNGPVxDmSR@xps13> References: <1414078550-692-1-git-send-email-sergio.gonzalez.monroy@intel.com> <91383E96CE459D47BCE92EFBF5CE73B004F0B593@IRSMSX107.ger.corp.intel.com> <3025851.uNGPVxDmSR@xps13> 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 <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Wed, 17 Dec 2014 18:50:06 -0000 2014-12-17 15:01, Thomas Monjalon: > 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 <sergio.gonzalez.monroy@intel.com> > > > > > --- > > > > > 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'm preparing a patch with the second approach. It raised other problems like error when linking examples with combined library. Patchset to come. > > 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