[dpdk-dev] [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y

[Neil Horman]

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