From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id E6C2AE82 for ; Fri, 3 Oct 2014 13:21:53 +0200 (CEST) Received: from [2001:470:8:a08:9833:6894:f2b2:43a] (helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1Xa12J-0007SQ-8C; Fri, 03 Oct 2014 07:28:40 -0400 Date: Fri, 3 Oct 2014 07:28:33 -0400 From: Neil Horman To: Sergio Gonzalez Monroy Message-ID: <20141003112833.GA24059@hmsreliant.think-freely.org> 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> <20141003103110.GB28988@sivswdev02.ir.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20141003103110.GB28988@sivswdev02.ir.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No 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 11:21:54 -0000 On Fri, Oct 03, 2014 at 11:31:10AM +0100, Sergio Gonzalez Monroy wrote: > 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 > Sorry, I wasn't trying to assert that it doesn't make sense to have a single shared library, but rather I was trying to assert that we should only _ever_ build a single shared library. I assert this because to create a single shared library destroys part of the advantage that DSO's have. Namely that they allow for selective hardware enablement in the field. I.e. you can ship your pmd's pacakged separately from your core, and not have to update your application (and pull them in via the -d option on the command line). If the dpdk builds everything as a single binary, then you may end up needing to pull in pmds that you don't yet need to support. In short, my initial idea was dumb :) Neil > > > > > 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. > > > >