Re: [PATCH] mk: fix acl library static linking
From: Thomas Monjalon <hidden>
Date: 2016-06-30 15:36:14
2016-06-30 15:02, Sergio Gonzalez Monroy:
On 30/06/2016 13:44, Thomas Monjalon wrote:quoted
2016-06-30 13:04, Sergio Gonzalez Monroy:quoted
On 30/06/2016 12:38, Thomas Monjalon wrote:quoted
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
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.
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.