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 1B5F4E82 for ; Fri, 3 Oct 2014 13:25:49 +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 1Xa16B-0007UX-4X; Fri, 03 Oct 2014 07:32:40 -0400 Date: Fri, 3 Oct 2014 07:32:34 -0400 From: Neil Horman To: Thomas Monjalon Message-ID: <20141003113234.GB24059@hmsreliant.think-freely.org> References: <1412265386-26291-1-git-send-email-sergio.gonzalez.monroy@intel.com> <2041475.WSUx3LgNfR@xps13> <20141003081019.GA28988@sivswdev02.ir.intel.com> <2274825.SfVmqUQfpO@xps13> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2274825.SfVmqUQfpO@xps13> 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:25:49 -0000 On Fri, Oct 03, 2014 at 10:27:30AM +0200, Thomas Monjalon wrote: > 2014-10-03 09:10, Sergio Gonzalez Monroy: > > On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote: > > > 2014-10-02 13:04, Matthew Hall: > > > > 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) > > > > > > > > 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. > > > > > > > > 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. > > > > > > We need to simplify build options. So I'm fine to remove COMBINE_LIBS option > > > to always enable it. > > > About making only one single static library, I think it's a good idea if > > > it brings a real code simplification. > > > > > > So the conclusion is to nack this patchset in favor of above changes. > > > Sergio, comments? > > > > > > > Frankly I did not think of users linking against single and combine lib for > > different apps. > > I think If the goal is to simplify code then we should just provide one build > > option, either single or combine. Personally, I do not have a preference. > > > > So just to be clear, we would remove COMBINE_LIBS to always make a single combine > > lib or to create both single and combine? > > For the later option, would we be linking apps against single or combine libraries? > > The proposal is to always build single (combined) lib AND to build separated > libs in case of shared libraries. > For static library: only one single (combined) static library. > This makes good sense to me. A single archive is just easier in the static case, since the resulting binary will strip out unused code anyway, and multiple libraries are needed in the shared case so that we don't wind up having to load more code than is needed at run time. Neil > -- > Thomas >