Hi Thomas, > -----Original Message----- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Sergio Gonzalez Monroy > Sent: Thursday, June 30, 2016 3:02 PM > To: Thomas Monjalon > Cc: dev at 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
