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 ;)


Reply via email to