On Fri, Oct 03, 2014 at 02:21:50PM -0700, Matthew Hall wrote:
> On Fri, Oct 03, 2014 at 03:15:46PM -0400, Neil Horman wrote:
> > With a single archive, you get everything you build even if you don't need
> > it.
>
> Right, I was trying to avoid that for people who specifically didn't want it,
>
On Fri, Oct 03, 2014 at 04:52:40PM -0700, Stephen Hemminger wrote:
> On Fri, 3 Oct 2014 07:28:33 -0400
> Neil Horman wrote:
>
> > I.e. you can ship your pmd's
> > pacakged separately from your core
>
> I was hoping only the application API would be "stable"
> As we know from Linux kernel, inter
On Fri, 3 Oct 2014 07:28:33 -0400
Neil Horman wrote:
> I.e. you can ship your pmd's
> pacakged separately from your core
I was hoping only the application API would be "stable"
As we know from Linux kernel, internal API's will never remain stable.
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
> > multip
On Fri, Oct 03, 2014 at 03:15:46PM -0400, Neil Horman wrote:
> With a single archive, you get everything you build even if you don't need
> it.
Right, I was trying to avoid that for people who specifically didn't want it,
if there are any... I'm not one of them.
> But presumably if you're build
On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote:
> On Thu, Oct 02, 2014 at 01:04:20PM -0700, Matthew Hall wrote:
> > 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 t
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 havin
On Fri, Oct 03, 2014 at 10:27:30AM +0200, Thomas Monjalon wrote:
> 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.
In the static case, this won't be backward compatible
On Fri, Oct 03, 2014 at 09:15:20AM +0200, Thomas Monjalon wrote:
> 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 concl
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
> > >
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
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
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
On Fri, Oct 03, 2014 at 11:31:10AM +0100, Sergio Gonzalez Monroy wrote:
> On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote:
> > On Thu, Oct 02, 2014 at 01:04:20PM -0700, Matthew Hall wrote:
> > > On Thu, Oct 02, 2014 at 01:26:34PM -0400, Neil Horman wrote:
> > > > Just out of curiosity,
On Thu, Oct 02, 2014 at 02:10:55PM -0700, Matthew Hall wrote:
> On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote:
> > This seems somewhat irrelevant to the patch. The default configuration is
> > already the way you want it to be, shared library performance is actually
> > very
> > clo
When building DPDK with CONFIG_RTE_BUILD_COMBINE_LIBS=y, the result is not
the expected behavior.
- It does link the combine library using LD instead of CC which results
in application linking errors.
- It creates both individual libraries and combine library, then linking
applications against
On Thu, Oct 02, 2014 at 01:04:20PM -0700, Matthew Hall wrote:
> 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
On Thu, Oct 02, 2014 at 04:24:51PM -0400, Neil Horman wrote:
> This seems somewhat irrelevant to the patch. The default configuration is
> already the way you want it to be, shared library performance is actually very
> close to static performance, and yes, people can choose how they want to
> bu
On Thu, Oct 02, 2014 at 04:56:22PM +0100, Sergio Gonzalez Monroy wrote:
> When building DPDK with CONFIG_RTE_BUILD_COMBINE_LIBS=y, the result is not
> the expected behavior.
>
> - It does link the combine library using LD instead of CC which results
> in application linking errors.
>
> - It cr
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
20 matches
Mail list logo
