DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: Matthew Hall <mhall@mhcomputing.net>
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 15:15:46 -0400	[thread overview]
Message-ID: <20141003191546.GD24059@hmsreliant.think-freely.org> (raw)
In-Reply-To: <20141003181713.GC1741@mhcomputing.net>

On Fri, Oct 03, 2014 at 11:17:13AM -0700, Matthew Hall wrote:
> On Fri, Oct 03, 2014 at 07:32:34AM -0400, Neil Horman wrote:
> > 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
> 
> This assertion is not true. Because the DPDK doesn't work if you don't specify 
> the whole-archive link option. Which explicitly prevents stripping out any 
> "unused code". Otherwise your PMD's will refuse to initialize.
> 
I'm not asserting that you remove the --whole-archive option, only that the
we assemble all objects into a single archive during the SDK build.  Its just a
convienience, because the application binary result will be the same, regardless
of weather you link several small archives, or a single large one (because of
the aforementioned --whole-archive option).  The only remaining issue is events
where an application doesn't need (for example) the acl library, or other
optional library.  With a single archive, you get everything you build even if
you don't need it.  But presumably if you're building a static binary, you're
likely building the dpdk as well and can configure optional libraries out of the
build.  Separate libraries are more a need for downstream
distributors/packagers, who use dynamic shared objects anyway.
 
> This along with backward compatibility is why I was advising to build the full 
> static library and the sublibraries so it will just work for everybody by 
> default.
> 
Backward compatibilty?  the DPDK doesn't yet provide run time compatibility
between releases (something I've been trying to change).  Nobody provides
compile time compatibility.  To do so would require fixing API's permenently.

Neil

  reply	other threads:[~2014-10-03 19:09 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
2014-10-03 18:17             ` Matthew Hall
2014-10-03 19:15               ` Neil Horman [this message]
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=20141003191546.GD24059@hmsreliant.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=mhall@mhcomputing.net \
    /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).