[dpdk-dev] Impossible to build external application if user build DPDK with "make config"

Thomas Monjalon thomas at monjalon.net
Fri Mar 27 14:55:14 CET 2020


27/03/2020 13:35, Tom Barbette:
> Le 27/03/2020 à 11:35, Thomas Monjalon a écrit :
> > 27/03/2020 10:14, Tom Barbette:
> >> CC'ing original participants as I don't see a way out of this.
> >>
> >> Le 12/03/2020 à 13:04, Tom Barbette a écrit :
> >>> Hi all,
> >>>
> >>> If the user follows the quick guide
> >>> (http://core.dpdk.org/doc/quick-start/) DPDK will be compiled in the
> >>> "build" folder.
> >>>
> >>> However, external applications will always fail to build because
> >>> RTE_SDK_BIN is strictly defined as $RTE_SDK/$RTE_TARGET, and
> >>> mk/internal/rte.extvars.mk needs to find .config in $RTE_SDK_BIN.
> >>>
> >>> Therefore please apply the patch at:
> >>> http://patchwork.dpdk.org/patch/9991/ that allows external apps to
> >>> override $RTE_SDK_BIN.
> >>>
> >>> Or (less preferable) modify the quick start guide to use something more
> >>> standard that allows to build with external apps (eg use the menu or
> >>> propose "make config T=x86_64-native-linuxapp-gcc
> >>> O=x86_64-native-linuxapp-gcc" instead). It's much easier for external
> >>> apps maintainer to refer to the DPDK tutorial for DPDK installation.
> > 
> > I don't understand the issue.
> > First of all, the external application should link an installed DPDK.
> > Then you should be able to set $RTE_SDK and $RTE_TARGET to fit
> > the installation directories.
> > 
> > Just checked doc/guides/linux_gsg/build_dpdk.rst
> > I see the whole build process with make is not correctly documented.
> > It should be:
> > 
> > 1/
> > 	make defconfig
> > 	or
> > 	make config T=x86_64-native-linux-gcc O=mybuild
> > 
> > 2/	make -j4 O=mybuild
> > 
> > 3/	make install O=mybuild DESTDIR=myinstall prefix=
> > 
> > 4/	RTE_SDK=$(pwd)/myinstall/share/dpdk RTE_TARGET=x86_64-native-linux-gcc make -C myapp
> > 
> > Please can you confirm it works?
> > 
> > 
> 
> I don't think it is usual to link against an "installed" DPDK, actually. 
> I've only seen people explaining "build DPDK with 1 & 2", which is 
> probably why the quick start also use only that and the usertools menu 
> also only builds in the usual folder SDK/TARGET.
> 
> Then also using the install method you propose, I'm missing a few 
> libraries, eg -lethdev which I would have to find using 
> -L$RTE_SDK/../../lib which does not sound great. But adding a link to 
> ../../lib under share fixes the problem, and the install script could do it.

Why are you trying to link a library in RTE_SDK?
You should set the installed library directory with LD_LIBRARY_PATH.

> Making RTE_SDK_BIN a ?= instead of a := would allow us to fix the 
> non-installed, but built-in-a-funny-folder installation path easily.
> 
> So I would recommend doing the lib link, but still the change proposed 
> because I'm really not sure people "install" DPDK...

The correct method is installing the library and using standard environment variables.
The only change I am OK to do is improving the documentation.




More information about the dev mailing list