Re: [dpdk-dev] [PATCH] mk: fix acl library static linking

["Ananyev, Konstantin" <konstantin.ananyev@intel.com>]

Hi Thomas,

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Sergio Gonzalez Monroy
> Sent: Thursday, June 30, 2016 3:02 PM
> To: Thomas Monjalon
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH] mk: fix acl library static linking
> 
> On 30/06/2016 13:44, Thomas Monjalon wrote:
> > 2016-06-30 13:04, Sergio Gonzalez Monroy:
> >> On 30/06/2016 12:38, Thomas Monjalon wrote:
> >>> Does it need to be commented in rte.app.mk?
> >>> The other libs are in whole-archive to support dlopen of drivers.
> >>> But the problem here is not because of a driver use.
> >> There seem to be a bunch of libraries under --whole-archive scope that
> >> are not
> >> PMDs, ie. cfgfile, cmdline...
> >>
> >> What is the criteria?
> > The criteria is a bit vague. We must try to include only libs which can
> > be used by a driver.
> > cmdline should probably not be there.
> > Does it make sense to use cfgfile in a driver? maybe yes.
> 
> So as it is, ACL autotest is broken when building static libs
> (non-combined).
> For combined libs we usually wrap libdpdk.a with --whole-archive, thus it is
> not an issue.
> 
> Just thinking a bit more about the 'dlopen of drivers' case you
> mentioned before,
> shouldn't the driver have proper dependencies and therefore need shared
> DPDK libraries?
> What does happen if binary/app and driver are built against different
> library versions?
> Where does it say that we do support this use case?
> 
> Sergio
> 

So are you going to apply this patch?
Right now acl just can't be used properly in case of static library build.
Thanks
Konstantin