On 30/06/2016 16:28, Thomas Monjalon wrote: > 2016-06-30 15:02, Sergio Gonzalez Monroy: >> 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). > I think the --whole-archive option must be set specifically for ACL > with a comment explaining it is required because of weak functions: > > # librte_acl needs --whole-archive because of weak functions > _LDLIBS-$(CONFIG_RTE_LIBRTE_ACL) += --whole-archive -lrte_acl > --no-whole-archive
Will do. >> 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? > It is possible to build a .so, without any DT_NEEDED entries, which will > find the required symbols in the static linked binary. Of course! All DPDK libraries were like that until recently. That doesn't mean it was right though. >> What does happen if binary/app and driver are built against different >> library versions? > Bad things :) > >> Where does it say that we do support this use case? > It is maybe not written. But I know it is used by people wanting to load > some PMD.so on demand while having the rest statically compiled. > I agree it needs to be documented and probably better managed and tested. > Note that this only applies to apps built with DPDK build system. In my opinion, I don't think we should be supporting such case. But if we were to, we are probably just better of whole-archiving all libraries into the application. For example, what if there was a driver wanting to use ACL or any other DPDK lib not currently in the set of libs we "consider" should be use by drivers? Also, from what I have seen in the list, most folks do end up using combined lib and wrapping it with --whole-archive. Sergio
