From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id E0A2D1B292 for ; Mon, 2 Oct 2017 22:48:50 +0200 (CEST) Received: from orsmga004.jf.intel.com ([10.7.209.38]) by fmsmga101.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 02 Oct 2017 13:48:40 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.42,471,1500966000"; d="scan'208,217";a="134455342" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by orsmga004.jf.intel.com with ESMTP; 02 Oct 2017 13:48:40 -0700 Received: from fmsmsx114.amr.corp.intel.com (10.18.116.8) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Mon, 2 Oct 2017 13:48:29 -0700 Received: from fmsmsx108.amr.corp.intel.com ([169.254.9.100]) by FMSMSX114.amr.corp.intel.com ([169.254.6.69]) with mapi id 14.03.0319.002; Mon, 2 Oct 2017 13:48:29 -0700 From: "Eads, Gage" To: "dev@dpdk.org" CC: Olivier Matz , "'Jacob, Jerin'" , "santosh.shukla@caviumnetworks.com" Thread-Topic: Inter-PMD dependencies when building shared libraries Thread-Index: AdM7vMijedyhBJ/5TLqq5v3Rnbe+fQ== Date: Mon, 2 Oct 2017 20:48:29 +0000 Message-ID: <9184057F7FC11744A2107296B6B8EB1E14005F70@FMSMSX108.amr.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiMTRhMDgyOGYtZWMwOC00MTM2LTkwNmYtMTNiOTkzZDE5NWQ0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6ImxrN0d2bHVYYW5pUzRRYlR4VWFtOWMrUHRyK1p3OXpPdFdVbnFZK1ZxZ1k9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [10.1.200.107] MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: [dpdk-dev] Inter-PMD dependencies when building shared libraries 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: , X-List-Received-Date: Mon, 02 Oct 2017 20:48:51 -0000 I believe I've spotted an issue in the way inter-PMD dependencies are handl= ed when building shared libraries. The depdirs_rule in mk/rte.subdir.mk rel= ies on DEPDIRS-xyz containing the names of subdirectories that xyz depends = on. In mk/rte.lib.mk, these DEPDIRS are converted into LDLIBS. This works w= hen the subdirectory names match the library names (i.e. any of the librari= es under lib/). However when the dependency is on a PMD, the subdirectory a= nd library names don't match. This is a problem, for example, in a patch for the net/octeontx PMD, which = has a dependency on the event/octeontx PMD: http://dpdk.org/ml/archives/dev= /2017-August/073983.html I've reproduced this with a contrived example, by making the failsafe PMD d= epend on the NULL PMD in drivers/net/Makefile: -DEPDIRS-failsafe =3D $(core-libs) +DEPDIRS-failsafe =3D $(core-libs) librte_pmd_null You can reproduce the build failure by running this command: ./devtools/test-build.sh x86_64-native-linuxapp-gcc+CONFIG_RTE_BUILD_SHARED= _LIB I'm no expert on DPDK's dependency handling code, but one option is to modi= fy rte.lib.mk like so: -LDLIBS +=3D $(subst lib,-l,$(_LDDIRS)) +LDLIBS +=3D $(subst lib,-l,$(filter lib%,$(_LDDIRS))) Then you could put the PMD's directory name in DEPDIRs, and specify the dep= ended-on library in the PMD's LDLIBS (as is done in the aforementioned net/= octeontx PMD). Thoughts? Thanks, Gage