From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-5.2 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,USER_AGENT_SANE_1 autolearn=ham autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id DFFD2C43603 for ; Thu, 12 Dec 2019 11:45:01 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 7349D20663 for ; Thu, 12 Dec 2019 11:45:01 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 7349D20663 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id E8B1A1BE8A; Thu, 12 Dec 2019 12:44:59 +0100 (CET) Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 2C0D7374C for ; Thu, 12 Dec 2019 12:44:57 +0100 (CET) X-Amp-Result: UNKNOWN X-Amp-Original-Verdict: FILE UNKNOWN X-Amp-File-Uploaded: False Received: from orsmga008.jf.intel.com ([10.7.209.65]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 12 Dec 2019 03:44:57 -0800 X-IronPort-AV: E=Sophos;i="5.69,305,1571727600"; d="scan'208";a="208055993" 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:44:55 -0800 Date: Thu, 12 Dec 2019 11:44:51 +0000 From: Bruce Richardson To: Ferruh Yigit Cc: David Marchand , dev , Thomas Monjalon , "Kinsella, Ray" , Luca Boccassi Message-ID: <20191212114451.GA422@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1ed4a57a-289c-dad8-ef6b-97017c49cb2e@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 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 PS: No need to ask this question for meson, as there is no assumption that end user apps use any part of our build systems for their apps - it's managed through pkg-config only.