From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id B5B97A04F5; Thu, 12 Dec 2019 14:41:37 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 225A7374C; Thu, 12 Dec 2019 14:41:37 +0100 (CET) Received: from wout3-smtp.messagingengine.com (wout3-smtp.messagingengine.com [64.147.123.19]) by dpdk.org (Postfix) with ESMTP id 42B212BD3 for ; Thu, 12 Dec 2019 14:41:35 +0100 (CET) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.west.internal (Postfix) with ESMTP id EA6E874A; Thu, 12 Dec 2019 08:41:33 -0500 (EST) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Thu, 12 Dec 2019 08:41:34 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=+2fISCa/loyL2DfRpV+F1JHgtvfiLnm5uiHHS4+2rvk=; b=RCzB/2iTwtsc ZQ6zjBeaHmoqZSKmKm8lDMGcC4YgjrYulDyzPJZStfI5rP5VkNfJN0kjTPNJfmJk vnqdzHGgk6UX3n0wolgbO5MlXzUmEt8HHDSJCshZ6+aiILESjulTnbvJRJaqrNTL IDwgKttNYN3I7309GrEiz9eEkuNPWaI= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=+2fISCa/loyL2DfRpV+F1JHgtvfiLnm5uiHHS4+2r vk=; b=rsq7ckyJ/tMIlUSWMTUS1aPZn2bt+flTA/ep/KEcwom/6/NwnMAl+jbvl AEOAuOp6GEyS0JOnXYS/6s41psKQEdCSUmAHuTuSYyvdp1k8qqU8cWr0kzv4v8ti xN2o9orAK9khIXHXOx0YXYdXQ2vohUr3mB2JN1BafasV8qnee/VizNX6yK4NB0PN xuRt89Iy+puIkyojh1QmHZp7bHDlZy66s/uqXnn5Xb0NGJBhf3YNKPDsUuILjMgF cmErp0v9+EvYTh+FVHHl1Yoe/gsJKr6P5c2hHRINvjE7i/z4XBSjnjZu+BSiHMCU dVw9o4eFj/RAutMDmSp4NwzgoqAog== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedufedrudeljedgheeiucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvufffkfgjfhgggfgtsehtufertddttddvnecuhfhrohhmpefvhhhomhgr shcuofhonhhjrghlohhnuceothhhohhmrghssehmohhnjhgrlhhonhdrnhgvtheqnecuff homhgrihhnpehlihgsrdhmkhenucfkphepjeejrddufeegrddvtdefrddukeegnecurfgr rhgrmhepmhgrihhlfhhrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtnecuve hluhhsthgvrhfuihiivgeptd X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 94F333060112; Thu, 12 Dec 2019 08:41:32 -0500 (EST) From: Thomas Monjalon To: Bruce Richardson Cc: Ferruh Yigit , David Marchand , dev , "Kinsella, Ray" , Luca Boccassi Date: Thu, 12 Dec 2019 14:41:30 +0100 Message-ID: <1627408.3L9Xmy2NJP@xps> In-Reply-To: <20191212115938.GB422@bricha3-MOBL.ger.corp.intel.com> References: <20191211102642.983579-1-bruce.richardson@intel.com> <20191212114451.GA422@bricha3-MOBL.ger.corp.intel.com> <20191212115938.GB422@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v2] build: fix soname info for 19.11 compatiblity X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 12/12/2019 12:59, Bruce Richardson: > On Thu, Dec 12, 2019 at 11:44:51AM +0000, Bruce Richardson wrote: > > On Thu, Dec 12, 2019 at 08:57:50AM +0000, Ferruh Yigit wrote: > > > On 12/12/2019 8:27 AM, David Marchand wrote: > > > > Hello Bruce, > > > > > > > > On Wed, Dec 11, 2019 at 4:16 PM Bruce Richardson > > > > wrote: > > > >> > > > >> The soname for each stable ABI version should be just the ABI version major > > > >> number without the minor number. Unfortunately both major and minor were > > > >> used causing version 20.1 to be incompatible with 20.0. > > > >> > > > >> This patch fixes the issue by switching from 2-part to 3-part ABI version > > > >> numbers so that we can keep 20.0 as soname and using the final digits to > > > >> identify the 20.x releases which are ABI compatible. This requires changes > > > >> to both make and meson builds to handle the three-digit version and shrink > > > >> it to 2-digit for soname. > > > >> > > > >> Fixes: cba806e07d6f ("build: change ABI versioning to global") > > > >> > > > >> Signed-off-by: Bruce Richardson > > > >> Signed-off-by: Thomas Monjalon > > > > > > > > There is an issue with the ethtool example. > > > > > > > > INSTALL-APP server > > > > INSTALL-MAP server.map > > > > cat: /home/dmarchan/dpdk/examples/ethtool/lib/ABI_VERSION: No such > > > > file or directory > > > > CC rte_ethtool.o > > > > LD librte_ethtool.so.0. > > > > INSTALL-LIB librte_ethtool.so.0. > > > > gmake[3]: stat: > > > > /home/dmarchan/builds/i686-native-linux-gcc+shared+debug+default/examples/ethtool/lib/i686-native-linux-gcc/lib/librte_ethtool.so.0.: > > > > Too many levels of symbolic links > > > > == ethtool-app > > > > > > > > > > > > > > It is linking against itself, in 'examples/ethtool/lib/build/lib': > > > librte_ethtool.so -> librte_ethtool.so.0. > > > librte_ethtool.so.0. -> librte_ethtool.so.0. > > > > Yes. The issue is that this patch doesn't correct account for external libs > > using their own version numbers. The trivial fix for this, which I'll add > > in v3 is to make two small changes: > > > > 1. Use ?= rather than := when assigning to LIBABIVER in rte.lib.mk > > 2. Change the LIBABIVER in ethtool/lib to "1.0" rather than "1", since the > > code assumes that we have more than a single digit in our version numbers. > > > > Question: Do we need to officially support external libs using our build > > system? > > > > * If no (because we assume nobody uses it or otherwise), then we use the two > > one-line fixes above and job done. > > * If yes, then the makefile logic needs further work to support the case of > > having an arbitrary version number. Also, we need to look into the whole > > experimental detection logic, as that would probably not apply for external > > libs. > > > > /Bruce > > > Patch v3 now sent, on the assumption that the answer is "no", or the answer > is "yes, but we can fix that later" :-) Yes, that's reasonnable.