From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f43.google.com (mail-wm0-f43.google.com [74.125.82.43]) by dpdk.org (Postfix) with ESMTP id 7860391C2 for ; Tue, 7 Jun 2016 10:23:27 +0200 (CEST) Received: by mail-wm0-f43.google.com with SMTP id k204so57797780wmk.0 for ; Tue, 07 Jun 2016 01:23:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=from:to:cc:subject:date:message-id:user-agent:in-reply-to :references:mime-version:content-transfer-encoding; bh=a02n7FYUCSqGk1Cqv2owHoGQPU/IHhJ0jhLws31eVxE=; b=neXr4GD10tbMBQfwQtdtvUVnxkRqEZEt66rg2tVvJeU9ZiYa1b2UGbXWzxUjoAXFtZ m4h41MmDb9pS88pD9ov4t0nfXNXMWXqxMn4PF3ebf1floelo0Yvv0GCInmy6jjemCU5w sOSZu2tvjxgFYeSXN9V1ciH0Nsx39jr0DvK/Pwlay2p1hGYrzfdTzcwdSjyk86wnXZol Y73OKCxT1BsaC7JERIQ+MZBZRLCw6liLb8/AlvC/A87Ztaz6vh2yqXY+bNtlBLdRAs1n pY/AsTiKbkmWAaBMT+gy1oYmTJFtMCPh/kGbsU6Iz7lHlyiqwDtGP/38vPvuDdwjK0gh KwpQ== 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:user-agent :in-reply-to:references:mime-version:content-transfer-encoding; bh=a02n7FYUCSqGk1Cqv2owHoGQPU/IHhJ0jhLws31eVxE=; b=EsvjEqB/z1i9ogK4gblMfQeXAb2BiO/uM7UgAbRWcOv0HJtJmK4i5wj/irOnZKHt2Q SV4LYJaq+Dcur/aqExDZyLKiAFbHFJ6iG7YQi2VLgA/4q2FW63bOFUDhxN6j4S9iQZ3s WOSsD7TTDe6o2XHBbjY7mvEwOiuopUf8v7IB9TuTCYlf3OHS7YDXizUNF+32JhEskqTI wItZAFeC6anPiPjKRumMjHf1m2bFQbBlSb9pcb/6792MSjCcdJh/cTCBDibZNw080lM4 ntZ/oHNOXPq6+CdY3HqwrhNAQk5JG9BficYwbV6qhZiSQ9UsSo98t1ess2q2lRgkEUun dmfw== X-Gm-Message-State: ALyK8tKGGbNvPbcWOIUNAtoknhxx3/PtsYyt0opIJJQVrAQKxj3peWYg2dL3gPcYhZIOngb3 X-Received: by 10.194.3.51 with SMTP id 19mr21202239wjz.57.1465287807184; Tue, 07 Jun 2016 01:23:27 -0700 (PDT) Received: from xps13.localnet (184.203.134.77.rev.sfr.net. [77.134.203.184]) by smtp.gmail.com with ESMTPSA id d7sm18195933wmd.11.2016.06.07.01.23.26 (version=TLSv1/SSLv3 cipher=OTHER); Tue, 07 Jun 2016 01:23:26 -0700 (PDT) From: Thomas Monjalon To: Panu Matilainen Cc: Christian Ehrhardt , dev@dpdk.org Date: Tue, 07 Jun 2016 10:23:25 +0200 Message-ID: <2002436.ZXkkWWzaid@xps13> User-Agent: KMail/4.14.10 (Linux/4.5.4-1-ARCH; KDE/4.14.11; x86_64; ; ) In-Reply-To: <78bbf74c-9621-9094-a280-76ed9fc88393@redhat.com> References: <7920424.umDpp4ukym@xps13> <78bbf74c-9621-9094-a280-76ed9fc88393@redhat.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH] mk: fix underlinking issues of most librte libraries 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: Tue, 07 Jun 2016 08:23:27 -0000 2016-05-24 12:56, Panu Matilainen: > On 05/20/2016 08:08 PM, Thomas Monjalon wrote: > > 2016-05-20 18:50, Christian Ehrhardt: > >> The individual libraries have various cross dependencies. > >> This is already refelcted in the DEPDIR dependency, but not yet in > >> proper DT_NEEDED flags in the .so's. > >> This adds the -l flags so that is properly stored in the .so's ELF > >> headers. > > > > Why not filling LDLIBS by parsing DEPDIRS-y in rte.lib.mk? > > > > A fair question :) The thought has passed my mind too, but I thought > it'd be too messy with differing library vs directory names and other > exceptions. But in reality manually maintained separate LDLIBS is only > going to get out of sync sooner or later, and turns out its not that bad > anyway: > > diff --git a/mk/rte.lib.mk b/mk/rte.lib.mk > index b420280..88b4e98 100644 > --- a/mk/rte.lib.mk > +++ b/mk/rte.lib.mk > @@ -77,6 +77,12 @@ else > _CPU_LDFLAGS := $(CPU_LDFLAGS) > endif > > +# Translate DEPDIRS-y into LDLIBS > +IGNORE_DEPS = -lrte_eal/% -lrte_net -lrte_compat We need some comments to explain why they are ignored. > +_LDDIRS = $(subst librte_ether,libethdev,$(DEPDIRS-y)) > +_LDDEPS = $(subst lib/lib,-l,$(_LDDIRS)) > +LDLIBS += $(filter-out $(IGNORE_DEPS), $(_LDDEPS)) > I'm also sure somebody more familiar with gmake could improve it, but it > seems to work quite fine here. I'll wait a bit to see if there are other > suggestions before sending it as a proper patch. I'm familiar with gmake and I do not think it can be improved more ;) Please send a patch. Thanks