01/07/2020 17:45, Bruce Richardson: > On Wed, Jul 01, 2020 at 05:36:07PM +0200, Thomas Monjalon wrote: > > 01/07/2020 17:16, Bruce Richardson: > > > On Wed, Jul 01, 2020 at 04:42:33PM +0200, Thomas Monjalon wrote: > > > > 30/06/2020 16:14, Bruce Richardson: > > > > > When calling pkg-config --static --libs, pkg-config will always > > > > > output the > > > > > regular libs first, and then the extra libs from libraries.private > > > > > field, > > > > > > > > s/libraries.private/Libs.private/ > > > > > > > > > since the assumption is that those are additional dependencies for > > > > > building > > > > > statically that the .a files depend upon. > > > > > > > > > > However, for DPDK, we only link the driver files for static builds, > > > > > and > > > > > those need to come *before* the regular libraries. To get this > > > > > result, we > > > > > need two pkgconfig files for DPDK, one for the shared libs, and a > > > > > second > > > > > for the static libs and drivers, which depends upon the first. Using a > > > > > dependency means that the shared libs are printed only after the > > > > > libraries.private field rather than before. > > > > > > > > s/libraries.private/Libs.private/ > > > > > > > > > Without this patch, the linking works in DPDK because in all cases we > > > > > specify the libraries after the drivers in the Libs.private line, > > > > > ensuring > > > > > that the references to the libs from the drivers can be resolved. The > > > > > current output is therefore of the form, "(shared)libs, drivers, > > > > > (static)libs", while after this patch the output is, "drivers, > > > > > (static)libs, (shared)libs". The former case will not work if we use > > > > > the > > > > > --whole-archive flag on the static libs as it will lead to duplicate > > > > > definitions due to some references having been previously resolved > > > > > from the > > > > > shared libraries. By ensuring the shared libraries come last in the > > > > > link > > > > > link, this issue does not occur, as duplicate references when linking > > > > > the > > > > > shared libs will be ignored. > > > > > > > > > > Signed-off-by: Bruce Richardson <bruce.richard...@intel.com> > > > > > Acked-by: Luca Boccassi <bl...@debian.org> > > > > > Acked-by: Sunil Pai G <sunil.pa...@intel.com> > > > > > --- > > > > > +# When calling pkg-config --static --libs, pkg-config will always > > > > > output the > > > > > +# regular libs first, and then the extra libs from libraries.private > > > > > field, > > > > > +# since the assumption is that those are additional dependencies for > > > > > building > > > > > +# statically that the .a files depend upon. However, for DPDK, we > > > > > only link > > > > > +# the driver files for static builds, and those need to come > > > > > *before* the > > > > > +# regular libraries. To get this result, we need two pkgconfig files > > > > > for DPDK, > > > > > +# one for the shared libs, and a second for the static libs and > > > > > drivers, which > > > > > +# depends upon the first. Using a dependency means that the shared > > > > > libs are > > > > > +# printed only after the libraries.private field rather than before. > > > > > > > > This is not obvious. In order to avoid messing it up in future, > > > > I suggest this longer reword: > > > > > > > > # When calling pkg-config --static --libs, pkg-config will always > > > > output the > > > > # regular libs first, and then the extra libs from Libs.private field, > > > > # since the assumption is that those are additional dependencies for > > > > building > > > > # statically that the .a files depend upon. The output order of .pc > > > > fields is: > > > > # Cflags Libs Libs.private Requires Requires.private > > > > # The fields Requires* are for package names. > > > > # The flags of the DPDK libraries must be defined in Libs* fields. > > > > # However, the DPDK drivers are linked only in static builds > > > > (Libs.private), > > > > # and those need to come *before* the regular libraries (Libs field). > > > > # This requirement is satisfied by moving the regular libs in a > > > > separate file > > > > # included in the field Requires (after Libs.private). > > > > # Another requirement is to allow linking dependencies as shared > > > > libraries, > > > > # while linking static DPDK libraries and drivers. It is satisfied by > > > > # listing the static files in Libs.private with the explicit syntax > > > > -l:libfoo.a. > > > > # As a consequence, the regular DPDK libraries are already listed as > > > > static > > > > # in the field Libs.private. The second occurences of DPDK libraries, > > > > # included from Requires and used for shared library linkage case, > > > > # are skipped in the case of static linkage thanks to the flag > > > > --as-needed. > > > > > > > > # Link order summary: > > > > # libdpdk.Libs.private: whole-archive(static drivers/libs), drivers > > > > deps flags > > > > # libdpdk.Requires: libdpdk-libs package > > > > # libdpdk-libs.Libs: as-needed(shared libs) > > > > # libdpdk-libs.Libs.private: libs deps flags > > > > # libdpdk.pc.Requires.private: deps packages > > > > > > > > > > > > If you agree, I could change this comment while merging. > > > > I would add my Signed-off ;) > > > > > > > > > > This seems generally ok, but probably should just be added as part of > > > patch > > > #7 when all parts of the above have been applied. > > > > > > Couple of comments: > > > * One small nit is that cflags are not output as part of the --libs call, > > > so > > > you can remove them from the list on line 5 of the comment. They aren't > > > really relevant to this comment/essay. > > > > Yes, I will remove Cflags. > > > > > * I find the link-order summary to actually be more confusing than > > > helpful. > > > I think the text block is explanatory enough. It just confuses things > > > introducing the extra details of what goes in the requires-private or > > > libs-private of the libdpdk.pc file. That's just regular stuff, unrelated > > > to the changes or to DPDK special-case of needing private libs first. > > > > The intent of this summary was to help navigating > > for future changes in this area. > > Personnaly it helps me, but it is maybe more a developer note > > that can be deduced from the rest. > > I can remove it. > > > Ok thanks. If you are happy to make these comment changes on apply, please > feel free to do so, thanks. > > [BTW: I think the shebang line on the new python script needs a "python" > changed to "python3" also. I missed that in the latest revision, sorry!]
OK will do.
