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 10183A04F5; Thu, 12 Dec 2019 12:59:46 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id DAD3D374C; Thu, 12 Dec 2019 12:59:45 +0100 (CET) Received: from mga17.intel.com (mga17.intel.com [192.55.52.151]) by dpdk.org (Postfix) with ESMTP id 582B42BD3 for ; Thu, 12 Dec 2019 12:59:44 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga107.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2019 03:59:43 -0800 X-IronPort-AV: E=Sophos;i="5.69,305,1571727600"; d="scan'208";a="208059417" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.46]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-SHA; 12 Dec 2019 03:59:41 -0800 Date: Thu, 12 Dec 2019 11:59:38 +0000 From: Bruce Richardson To: Ferruh Yigit Cc: David Marchand , dev , Thomas Monjalon , "Kinsella, Ray" , Luca Boccassi Message-ID: <20191212115938.GB422@bricha3-MOBL.ger.corp.intel.com> References: <20191211102642.983579-1-bruce.richardson@intel.com> <20191211151628.1512802-1-bruce.richardson@intel.com> <1ed4a57a-289c-dad8-ef6b-97017c49cb2e@intel.com> <20191212114451.GA422@bricha3-MOBL.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20191212114451.GA422@bricha3-MOBL.ger.corp.intel.com> User-Agent: Mutt/1.12.1 (2019-06-15) 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" 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" :-)