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
