[dpdk-dev] Linking with -ldpdk

[dpdk-dev] Linking with -ldpdk

[tom.barbette]

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...

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)

Or maybe some of these libraries should be included in the dpdk static lib?

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

Thanks,

Tom

Re: [dpdk-dev] Linking with -ldpdk

[Bruce Richardson]

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...
> 
> 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)
> 
> Or maybe some of these libraries should be included in the dpdk static lib?
> 
> I use the last git version (but it's the same problem with previous ones).
> 
> Thanks,
> 
> Tom

Hi Tom,

this is something that I was hoping to achieve using pkg-config files
generated by the meson build system. This is still a work in progress,
but you can use "ninja install" to install a pkg-config file for DPDK at
the end of the build process, and the Makefiles for the DPDK examples
show how to build a static binary using that information. 

Now the limitations: there is no support for building all of DPDK as a
single static library, but pkg-config does provide the list of all DPDK
libs and drivers individually, as well as a list of the extra lib names
that have to be added to the end. [Given what pkg-config provides, I
fail to see the need to produce the single .a file any more too] Sadly
for the use case you mention above, the mlx* drivers aren't available as
part of the build yet either.

In the meantime, while the gaps are being filled out, any feedback on
building using pkg-config output would be appreciated. I admit it is a
bit more geared towards shared library building, but static should work
also.

Regards,
/Bruce

Re: [dpdk-dev] Linking with -ldpdk

[Neil Horman]

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
>