From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 0E9E67E0B for ; Thu, 30 Oct 2014 12:44:25 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga102.jf.intel.com with ESMTP; 30 Oct 2014 04:51:56 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.07,285,1413270000"; d="scan'208";a="628250388" Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157]) by orsmga002.jf.intel.com with ESMTP; 30 Oct 2014 04:53:20 -0700 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.82]) by IRSMSX103.ger.corp.intel.com ([169.254.3.56]) with mapi id 14.03.0195.001; Thu, 30 Oct 2014 11:53:19 +0000 From: "Gonzalez Monroy, Sergio" To: "Gonzalez Monroy, Sergio" , "dev@dpdk.org" Thread-Topic: [PATCH RFC] Update/Improve build system Thread-Index: Ac/y0Ygf71bGk8KHS4ikCUjA9ZJfwQBZnOLA Date: Thu, 30 Oct 2014 11:53:18 +0000 Message-ID: <91383E96CE459D47BCE92EFBF5CE73B004E9A155@IRSMSX108.ger.corp.intel.com> References: <91383E96CE459D47BCE92EFBF5CE73B004E97FFB@IRSMSX108.ger.corp.intel.com> In-Reply-To: <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] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [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 11:44:27 -0000 Hi, Apologies for the previous email format, I seems like I misconfigured somet= hing on my email-client. In case people find it annoying to read with extra line spaces, here is the= RFC with fixed formatting: 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