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 A1A51E82 for ; Fri, 3 Oct 2014 12:24:21 +0200 (CEST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by fmsmga101.fm.intel.com with ESMTP; 03 Oct 2014 03:31:14 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,646,1406617200"; d="scan'208";a="481719448" Received: from irvmail001.ir.intel.com ([163.33.26.43]) by azsmga001.ch.intel.com with ESMTP; 03 Oct 2014 03:31:12 -0700 Received: from sivswdev02.ir.intel.com (sivswdev02.ir.intel.com [10.237.217.46]) by irvmail001.ir.intel.com (8.14.3/8.13.6/MailSET/Hub) with ESMTP id s93AVBUr008222; Fri, 3 Oct 2014 11:31:11 +0100 Received: from sivswdev02.ir.intel.com (localhost [127.0.0.1]) by sivswdev02.ir.intel.com with ESMTP id s93AVBiK015046; Fri, 3 Oct 2014 11:31:11 +0100 Received: (from smonroy@localhost) by sivswdev02.ir.intel.com with id s93AVA8E015042; Fri, 3 Oct 2014 11:31:10 +0100 Date: Fri, 3 Oct 2014 11:31:10 +0100 From: Sergio Gonzalez Monroy To: Neil Horman Message-ID: <20141003103110.GB28988@sivswdev02.ir.intel.com> References: <1412265386-26291-1-git-send-email-sergio.gonzalez.monroy@intel.com> <20141002172634.GE4900@hmsreliant.think-freely.org> <20141002200420.GB29590@mhcomputing.net> <20141002202451.GF4900@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141002202451.GF4900@hmsreliant.think-freely.org> User-Agent: Mutt/1.5.20 (2009-06-14) Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y 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: Fri, 03 Oct 2014 10:24:22 -0000 On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote: > On Thu, Oct 02, 2014 at 01:04:20PM -0700, Matthew Hall wrote: > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote: > > > Just out of curiosity, whats the impetus behind a single shared library here? > > > Is it just to ease application linking operations? If so, it almost seems to me > > > that we should abandon the individual linking method and just use this as the > > > default output (and do simmilarly for the static linking build) > > > > > > Neil > > > > Not clear if you wrote "single shared library" on purpose instead of "single > > static library". But for me the objective of COMBINE_LIBS usage would be > > getting a "single static library" for my app, which just works, and eliminates > > need of start-group, end-group, weird library ordering issues, etc. I'm not > > interested personally in a "shared library" because it'd run slower. > > > Actually I do need to revise my question, thank you. you're right, doing a > single archive for static builds makes the most sense, because you wind up with > a static binary anyway, and as such, theres really no need for multiple dpdk > archives. We should just create a single dpdk.a file and be done with it. > > The shared libraries are a different story. While at first it made sense to me > to merge them all, it actually doesn't because PMD's might be built > independently and shipped separate from the core library. Sorry Neil, could you elaborate a bit on why it would not make sense to have a single/combined shared library? Sergio > > > Personally my preference would be to do both the single libs and multiple libs > > in static format by default. Disk space is cheap, let's maximize user freedom > > and flexibility. But shared lib, since it performs less well, should be > > discouraged by default, although allowed if needed... some people prefer it > > because it's easier to patch security vulns if you can replace a buggy library > > for all the code on a system. > > > This seems somewhat irrelevant to the patch. The default configuration is > already the way you want it to be, shared library performance is actually very > close to static performance, and yes, people can choose how they want to build. > Not sure what point your trying to make here. > Neil > > > Matthew. > >