From mboxrd@z Thu Jan 1 00:00:00 1970 From: Neil Horman Subject: Re: [PATCH 0/4] Fix build issues with CONFIG_RTE_BUILD_COMBINE_LIBS=y Date: Mon, 6 Oct 2014 10:45:31 -0400 Message-ID: <20141006144531.GC22304@hmsreliant.think-freely.org> References: <1412265386-26291-1-git-send-email-sergio.gonzalez.monroy@intel.com> <2041475.WSUx3LgNfR@xps13> <20141003081019.GA28988@sivswdev02.ir.intel.com> <2274825.SfVmqUQfpO@xps13> <20141003113234.GB24059@hmsreliant.think-freely.org> <20141003181713.GC1741@mhcomputing.net> <20141003191546.GD24059@hmsreliant.think-freely.org> <20141003212150.GA2637@mhcomputing.net> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Cc: dev-VfR2kkLFssw@public.gmane.org To: Matthew Hall Return-path: Content-Disposition: inline In-Reply-To: <20141003212150.GA2637-Hv3ogNYU3JfZZajBQzqCxQ@public.gmane.org> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces-VfR2kkLFssw@public.gmane.org Sender: "dev" 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, > if there are any... I'm not one of them. > > > 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. > > Yeah, I was thinking it'd be nice if the downstream packagers could get a > global '.a' and per-sublib '.a' as well. So that one dpdk package could be > used by a client app which wanted everything, or only wanted portions. > > > 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. > > Agreed. I was just advocating to avoid worsening the already existent issues. > ;) > > Matthew. > Fair enough Neil