From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <sergio.gonzalez.monroy@intel.com> Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id E097A5A85 for <dev@dpdk.org>; Thu, 29 Jan 2015 18:04:28 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by orsmga101.jf.intel.com with ESMTP; 29 Jan 2015 09:04:23 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.09,486,1418112000"; d="scan'208";a="519730980" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by orsmga003.jf.intel.com with ESMTP; 29 Jan 2015 08:57:07 -0800 Received: from irsmsx108.ger.corp.intel.com ([169.254.11.64]) by IRSMSX153.ger.corp.intel.com ([169.254.9.2]) with mapi id 14.03.0195.001; Thu, 29 Jan 2015 17:04:20 +0000 From: "Gonzalez Monroy, Sergio" <sergio.gonzalez.monroy@intel.com> To: Neil Horman <nhorman@tuxdriver.com> Thread-Topic: [dpdk-dev] [PATCH 0/8] Improve build process Thread-Index: AQHQO9csAhbRLFHQkk+N8RLUPQ4JH5zXTHuAgAACWfA= Date: Thu, 29 Jan 2015 17:04:20 +0000 Message-ID: <91383E96CE459D47BCE92EFBF5CE73B004F43D9B@IRSMSX108.ger.corp.intel.com> References: <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy@intel.com> <20150129163859.GE1999@hmsreliant.think-freely.org> In-Reply-To: <20150129163859.GE1999@hmsreliant.think-freely.org> 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 Cc: "dev@dpdk.org" <dev@dpdk.org> Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK <dev.dpdk.org> List-Unsubscribe: <http://dpdk.org/ml/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://dpdk.org/ml/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <http://dpdk.org/ml/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> X-List-Received-Date: Thu, 29 Jan 2015 17:04:29 -0000 > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Thursday, January 29, 2015 4:39 PM > To: Gonzalez Monroy, Sergio > Cc: dev@dpdk.org > Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process >=20 > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy wrote: > > This patch series improves the DPDK build system mostly for shared > > libraries (and a few nits for static libraries) with the following goal= s: > > - Create a library containing core DPDK libraries (librte_eal, > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > The idea of core libraries is to group those libraries that are > > always required (and have interdependencies) for any DPDK applicatio= n. > > - Remove config option to build a combined library. > > - For shared libraries, explicitly link against dependant > > libraries (adding entries to DT_NEEDED). > > - Update app linking flags for static/shared DPDK libs. > > > > Sergio Gonzalez Monroy (8): > > mk: remove combined library and related options > > core: create new librte_core > > mk: new corelib makefile > > lib: update DEPDIRS variable > > lib: set LDLIBS for each library > > mk: use LDLIBS when linking shared libraries > > mk: update LDLIBS for app building > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > > config/common_bsdapp | 6 -- > > config/common_linuxapp | 6 -- > > config/defconfig_ppc_64-power8-linuxapp-gcc | 2 - > > lib/Makefile | 1 - > > lib/librte_acl/Makefile | 5 +- > > lib/librte_cfgfile/Makefile | 4 +- > > lib/librte_cmdline/Makefile | 6 +- > > lib/librte_core/Makefile | 45 +++++++++++++ > > lib/librte_distributor/Makefile | 5 +- > > lib/librte_eal/bsdapp/eal/Makefile | 3 +- > > lib/librte_eal/linuxapp/eal/Makefile | 3 +- > > lib/librte_ether/Makefile | 4 +- > > lib/librte_hash/Makefile | 4 +- > > lib/librte_ip_frag/Makefile | 6 +- > > lib/librte_ivshmem/Makefile | 4 +- > > lib/librte_kni/Makefile | 6 +- > > lib/librte_kvargs/Makefile | 6 +- > > lib/librte_lpm/Makefile | 6 +- > > lib/librte_malloc/Makefile | 2 +- > > lib/librte_mbuf/Makefile | 2 +- > > lib/librte_mempool/Makefile | 2 +- > > lib/librte_meter/Makefile | 4 +- > > lib/librte_pipeline/Makefile | 3 + > > lib/librte_pmd_af_packet/Makefile | 5 +- > > lib/librte_pmd_bond/Makefile | 7 +- > > lib/librte_pmd_e1000/Makefile | 8 ++- > > lib/librte_pmd_enic/Makefile | 8 ++- > > lib/librte_pmd_i40e/Makefile | 8 ++- > > lib/librte_pmd_ixgbe/Makefile | 8 ++- > > lib/librte_pmd_pcap/Makefile | 5 +- > > lib/librte_pmd_ring/Makefile | 6 +- > > lib/librte_pmd_virtio/Makefile | 7 +- > > lib/librte_pmd_vmxnet3/Makefile | 8 ++- > > lib/librte_pmd_xenvirt/Makefile | 8 ++- > > lib/librte_port/Makefile | 8 +-- > > lib/librte_power/Makefile | 4 +- > > lib/librte_ring/Makefile | 2 +- > > lib/librte_sched/Makefile | 7 +- > > lib/librte_table/Makefile | 8 +-- > > lib/librte_timer/Makefile | 6 +- > > lib/librte_vhost/Makefile | 9 +-- > > mk/exec-env/linuxapp/rte.vars.mk | 2 + > > mk/rte.app.mk | 53 ++++----------- > > mk/rte.corelib.mk | 84 ++++++++++++++++++++= +++ > > mk/rte.lib.mk | 49 +++----------- > > mk/rte.sdkbuild.mk | 3 - > > mk/rte.sharelib.mk | 101 --------------------= -------- > > mk/rte.vars.mk | 9 --- > > 48 files changed, 276 insertions(+), 282 deletions(-) create mode > > 100644 lib/librte_core/Makefile create mode 100644 mk/rte.corelib.mk > > delete mode 100644 mk/rte.sharelib.mk > > > > -- > > 1.9.3 > > > > > Something occured to me thinking about this patch set. I noticed recentl= y > that different rules are used to build the shared combined lib from the > individual shared objects. The implication here is that linker options s= pecified > in individual make files (like the LIBABIVER and EXPORT_MAP options in my > ABI versioning script) get ignored, which is bad. Any other file specifi= c linker > options (like <file>_LDFLAGS specified in individual library makefiles ar= e > getting dropped for the combined lib. >=20 > It seems like it would be better if the combined libs were manufactured a= s > linker scripts themselves (textfiles that used linker directives to inclu= de > individual libraries under the covers (see /lib64/libc.so for an example)= . >=20 > The disadvantage of such an approach are fairly minimal. With such a > combined library, you still need to install individual libraries, but for > applications that wish to link and run against a single dpdk library will= still work > just as they currently do, you can link to just a single library. >=20 > The advantage is clear however. By following a linker script aproach, ob= jects > build as separate libraries are built exactly the same way, using the sam= e > rules with the same options. It reduces the dpdk build environment size = and > complexity, and reduces the opportunity for bugs to creep in from forgett= ing > to add build options to multiple locations. It also provides a more gran= ular > approach for grouping files. Creating a dpdk core library becomes a matt= er of > creating a one line linker script named libdpdk_core.so, rather than re- > arraning sections of the build system. >=20 > Thoughts? > Neil >=20 Hi Neil, I think that is a very interesting approach. I have tried to do something similar in this patch by removing rte.sharelib= .mk and just having rte.lib.mk to do the linking, leaving as you suggest a single f= ile to modify anything related to building libs. I do think however that your proposal is an improvement over the current pa= tch. So basically we want: - get rid of rte.corelib.mk - generate librte_core.so linker script grouping core libs - we do not modify DEPDIR variables - when setting LDLIBS to each lib, we do specify -lrte_core, right? Regards, Sergio