2016-06-13 11:04, Ferruh Yigit: > On 6/13/2016 10:29 AM, Thomas Monjalon wrote: > > 2016-06-10 19:32, Ferruh Yigit: > >> As stated in the comment: > >> Order is important: from higher level to lower level > >> > >> This is an attempt to make the layering order better respected. > >> > >> Limit scope of --whole-archive to pmd libraries > > > > Compared to the link order in the v2, you did two things: > > 1/ move PMDs to the first position > > 2/ restrict --whole-archive to PMDs only > > > > Having the PMDs first, helps the linker to get all the PMD dependencies > > in the static binary. Thus it seems we do not need --whole-archive > > for the PMD dependencies (ethdev, mbuf, etc). > > But, if an external PMD is loaded via dlopen, it is possible that it > > needs a symbol which was not used by the internal PMDs. So it will not > > be found in the statically linked binary. > > Let's take another example: if we disable the internal PMDs with their > > config options from the static build, and we decide to build them > > separately as DSOs. We won't be able to load them as plugins because > > they depend on symbols which won't be found in the static binary. > > So you want to keep all objects in final binary (used or unused) because > of the possibility that any plugin may use them.
Yes > But what is the list to include here, whole dpdk?, -since we may not > know what API will plugin call. The list of the libraries candidates to be called from a driver can be discussed. The top layers like lpm or distributor should not be in this list I think. > What I am confused is --whole-archive only used when dpdk compiled as > static, if dpdk compiled as shared, each PMD should have proper > dependencies [1], and if external PMD compiled properly there shouldn't > be a problem. So do we have a case that dpdk compiled statically into > final binary but we still want to load some plugins dynamically? Yes a plugin can be loaded from a static binary. Breaking this feature would need a separate discussion and notices. > > To make it short, the PMDs must be considered as plugins. Therefore, we > > must not rely on their availability to link the required symbols in > > a static binary. > > To make sure the plugin loading will be always well achieved, we must > > link the static PMDs at the last position. > > I think this is not the issue of linking PMD's first or last, but > expanding --whole-archive to cover other libraries other than PMDs. Yes, linking PMD at the end is a way to force us to keep some libraries in --whole-archive. > > If you agree, I vote for the v2 of this patchset. > > If this is breaking something and best way to fix is not in external PMD > but in here, please feel free to go with v2. I don't see any other solution. But I'm sure we could discuss it more and/or improve it in the future.
