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.
