DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>
Cc: dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y
Date: Fri, 3 Oct 2014 07:32:34 -0400	[thread overview]
Message-ID: <20141003113234.GB24059@hmsreliant.think-freely.org> (raw)
In-Reply-To: <2274825.SfVmqUQfpO@xps13>

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
> 

  reply	other threads:[~2014-10-03 11:25 UTC|newest]

Thread overview: 50+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-10-02 15:56 Sergio Gonzalez Monroy
2014-10-02 15:56 ` [dpdk-dev] [PATCH 1/4] Link combined shared library using CC Sergio Gonzalez Monroy
2014-10-02 15:56 ` [dpdk-dev] [PATCH 2/4] Do not generate individual libs when configured with RTE_BUILD_COMBINE_LIBS=y Sergio Gonzalez Monroy
2014-10-02 20:00   ` Matthew Hall
2014-10-02 15:56 ` [dpdk-dev] [PATCH 3/4] Link apps only against combined lib or individual libs, not both Sergio Gonzalez Monroy
2014-10-02 15:56 ` [dpdk-dev] [PATCH 4/4] Cleanup Sergio Gonzalez Monroy
2014-10-02 17:26 ` [dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y Neil Horman
2014-10-02 20:04   ` Matthew Hall
2014-10-02 20:24     ` Neil Horman
2014-10-02 21:10       ` Matthew Hall
2014-10-03  0:52         ` Neil Horman
2014-10-03 10:31       ` Sergio Gonzalez Monroy
2014-10-03 11:28         ` Neil Horman
2014-10-03 23:52           ` Stephen Hemminger
2014-10-04  2:30             ` Neil Horman
2014-10-03  7:15     ` Thomas Monjalon
2014-10-03  8:10       ` Sergio Gonzalez Monroy
2014-10-03  8:27         ` Thomas Monjalon
2014-10-03 11:32           ` Neil Horman [this message]
2014-10-03 18:17             ` Matthew Hall
2014-10-03 19:15               ` Neil Horman
2014-10-03 21:21                 ` Matthew Hall
2014-10-06 14:45                   ` Neil Horman
2014-10-03 18:13           ` Matthew Hall
2014-10-03 18:00       ` Matthew Hall
2014-10-06 10:52 ` [dpdk-dev] [PATCH v2 0/4] Update build process Sergio Gonzalez Monroy
2014-10-06 10:52   ` [dpdk-dev] [PATCH v2 1/4] Link combined shared library using CC Sergio Gonzalez Monroy
2014-10-06 10:52   ` [dpdk-dev] [PATCH v2 2/4] Link apps only against single/combined library Sergio Gonzalez Monroy
2014-10-06 10:52   ` [dpdk-dev] [PATCH v2 3/4] Update library build process Sergio Gonzalez Monroy
2014-10-06 20:46     ` Matthew Hall
2014-10-07  9:55       ` Sergio Gonzalez Monroy
2014-10-08 22:36         ` Matthew Hall
2014-10-09  9:44           ` Sergio Gonzalez Monroy
2014-10-08 15:38     ` Thomas Monjalon
2014-10-06 10:52   ` [dpdk-dev] [PATCH v2 4/4] Link apps/DSOs against EXECENV_LDLIBS with --as-needed Sergio Gonzalez Monroy
2014-10-08 15:38     ` Thomas Monjalon
2014-10-09  9:23       ` Sergio Gonzalez Monroy
2014-10-06 14:49   ` [dpdk-dev] [PATCH v2 0/4] Update build process Neil Horman
2014-10-06 15:01     ` Sergio Gonzalez Monroy
2014-10-06 16:05       ` Neil Horman
2014-10-09 13:04   ` [dpdk-dev] [PATCH v3 0/6] Update libs " Sergio Gonzalez Monroy
2014-10-09 13:04     ` [dpdk-dev] [PATCH v3 1/6] Link combined shared library using CC Sergio Gonzalez Monroy
2014-10-09 13:04     ` [dpdk-dev] [PATCH v3 2/6] Link apps only against single/combined library Sergio Gonzalez Monroy
2014-10-09 13:04     ` [dpdk-dev] [PATCH v3 3/6] Remove CONFIG_RTE_BUILD_COMBINE_LIBS and related Sergio Gonzalez Monroy
2014-10-09 13:04     ` [dpdk-dev] [PATCH v3 4/6] Update library build process Sergio Gonzalez Monroy
2014-10-09 13:04     ` [dpdk-dev] [PATCH v3 5/6] Avoid duplicated code Sergio Gonzalez Monroy
2014-10-09 13:04     ` [dpdk-dev] [PATCH v3 6/6] Link apps/DSOs against EXECENV_LDLIBS with --as-needed Sergio Gonzalez Monroy
2014-10-13 16:01     ` [dpdk-dev] [PATCH v3 0/6] Update libs build process Gonzalez Monroy, Sergio
2014-10-21  9:43       ` Gonzalez Monroy, Sergio
2014-10-22 16:14         ` Gonzalez Monroy, Sergio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20141003113234.GB24059@hmsreliant.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=thomas.monjalon@6wind.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).