Re: [dpdk-dev] Linking with -ldpdk

[Neil Horman <nhorman@tuxdriver.com>]

On Mon, Feb 19, 2018 at 10:39:39AM +0100, tom.barbette@uliege.be wrote:
> Hi list,
> 
> I found out that to staticly compile against DPDK using the combined lib, I needed all these options :
> 
> -I${RTE_SDK}/${RTE_TARGET}/include -L${RTE_SDK}/${RTE_TARGET}/lib -Wl,--whole-archive -ldpdk -Wl,--no-whole-archive -lnuma -ldl -lpthread -lm -lmlx4 -lmlx5 -libverbs
> 
> The whole-archive makes sense, as we need to embed drivers that wouldn't be found at linking time (failing to include it prevents port discovery).
> However it leads to missing inclusion. That's why I added all the libs at the end of the line. The mlx4 libs particularly leads me to think that there must be a more programmatic way, portable accross versions of DPDK to find out which libraries referenced in DPDK I should include, right? Morveover if the DPDK user didn't include mlx4, it will fail to compile...
> 
Thats really the problem with static linking, theres no built-in dependency
tracking, the way the DT_NEEDED entries provide in dynamic linking.  The build
environment is responsible for understanding the libraries needed to resolve all
the symbols that an application and its libraries require at compile time.  In
the case of the mlx drivers, I beleive there is an effort to break the symbol
dependency by using the dlopen interface to resolve those symbols at run time,
but the scope of that effort is strictly for the mellanox drivers.  You still
need to manually track the numa, pthreead, math, etc libraries.

> What should I use? (the whole rte.extapp.mk DPDK build process is not an option as the build system is rather complex in this project)
> 
I'd recommend building dpdk as a shared library.  Then the DSO embodies the
subordonate libraries that have to be loaded by the linker at run time, and you
don't have to worry about it at all.  You just have to link with -ldpdk (the
shared build creates a linker script called dpdk.so that automagically pulls in
all the component DSOs).

> Or maybe some of these libraries should be included in the dpdk static lib?
> 
Thats not a scalable solution.  Some libraries don't have static versions that
you can link to (or don't have versions that build commonly as such).  And even
if they do, determining if you need to link them is a bit of a trick.  As Bruce
notes, he's trying to use package-config to solve the problem, but that tool
isnt meant for conditional compilation.  

> I use the last git version (but it's the same problem with previous ones).
> 
> Thanks,
> 
> Tom
>