From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga14.intel.com (mga14.intel.com [192.55.52.115]) by dpdk.org (Postfix) with ESMTP id 83012683B for ; Thu, 30 Oct 2014 10:11:13 +0100 (CET) Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga103.fm.intel.com with ESMTP; 30 Oct 2014 02:13:54 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208,217";a="408387516" Received: from irsmsx102.ger.corp.intel.com ([163.33.3.155]) by FMSMGA003.fm.intel.com with ESMTP; 30 Oct 2014 02:11:47 -0700 Received: from irsmsx107.ger.corp.intel.com (163.33.3.99) by IRSMSX102.ger.corp.intel.com (163.33.3.155) with Microsoft SMTP Server (TLS) id 14.3.195.1; Thu, 30 Oct 2014 09:18:24 +0000 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.82]) by IRSMSX107.ger.corp.intel.com ([169.254.10.21]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 09:18:24 +0000 From: "Gonzalez Monroy, Sergio" To: "dev@dpdk.org" Thread-Topic: [PATCH RFC] Update/Improve build system Thread-Index: Ac/y0Ygf71bGk8KHS4ikCUjA9ZJfwQ== Date: Thu, 30 Oct 2014 09:18:23 +0000 Message-ID: <91383E96CE459D47BCE92EFBF5CE73B004E97FFB@IRSMSX108.ger.corp.intel.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.181] 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] [PATCH RFC] Update/Improve build system 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: Thu, 30 Oct 2014 09:11:15 -0000 Hi, I would like to propose an update on the way the libraries are being built = on DPDK. Motivation/Issues: - No agreement on libraries to build (separated, combined, different groupi= ng). - People having issues building their applications cannot rely on the infor= mation given by ldd when using shared libraries because currently we are no= t building against dependent libraries. - External library dependencies are introduce in multiple places (ie. when = building librte_vhost, -lfuse is added into the lib CFLAGS, LDFLAGS and als= o need to update rte.app.mk). - Do we want to keep support for building shared libraries using LD? Curren= tly unused as both Linux and BSD enable linking using CC. Proposal: - Define external lib dependencies per module/lib/dir. ie. EXT_DEP_LIBS =3D= -lfuse -lm - Define internal lib dependencies per module/lib/dir. ie. DPDK_DEP_LIBS = =3D -lrte_eal - Remove compile config option CONFIG_RTE_BUILD_COMBINE_LIBS and always bui= ld all wanted libraries (see below about different libraries to build). - Shared linking: we want to link apps and libs against dependant libraries= . Basically add EXT_DEP_LIBS and DPDK_DEP_LIBS when linking libs and apps. - Static linking: we want to link apps against dependant libraries. >>From my point of view, we can classify DPDK libraries into three categories= (note that not all libraries are included and the following is just for il= lustration purposes): CORE_LIBS: librte_kvargs, librte_mbuf, librte_malloc, librte_mempool, librt= e_ring, librte_eal, libethdev? NON_CORE_LIBS: librte_vhost, librte_cfgfile, librte_cmdline, librte_sched, = librte_lpm, librte_acl, ... PMD_LIBS: librte_pmd_i40e, librte_pmd_e1000, librte_ixgbe, ... IMHO CORE_LIBS are a set of libraries that have inter-dependencies and are = always required to build an application. Such set of core libraries should = be provided as a single library. I can think of a few different ways to go about this: A) Build just one combined library for static or shared libraries. Pros: it would reduce and simplify makefile rules, as well as make it = easier for users to build their own apps against DPDK. Cons: limited flexibility when building custom apps with selected libr= aries. Link apps with something like: --whole-archive -ldpdk --no-whole-archive --as-needed $(EXT= _DEP_LIBS) --no-as-needed B) Build CORE_LIBS (as a single lib, librte_core), NON_CORE_LIBS and PMD_LI= BS: Pros: flexibility. Cons: more complex build process, as we would add dependencies for eac= h NON_CORE_LIB and PMD_LIB. Link apps with something like: --whole-archive $(PMD_LIBS) --no-whole-archive $(NON_CORE_L= IBS) -lrte_core --as-needed $(EXT_DEP_LIBS) --no-as-needed C) Similar to B but building a single library containing both CORE_LIBS and= NON_CORE_LIBS. Link apps with something like: --whole-archive $(PMD_LIBS) --no-whole-archive -lrte_xxxx -= -as-needed $(EXT_DEP_LIBS) --no-as-needed D) Build all libs in both A) and B) but linking DPDK provided apps only aga= inst combined lib for slightly simpler makefile rules. I would say that D) is a good balance, although not being the simplest. Thoughts? Thanks, Sergio