27/03/2020 15:24, Tom Barbette: > > Le 27/03/2020 à 14:55, Thomas Monjalon a écrit : > > 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. > > I don't want DPDK to be installed system-wide. I have a lot of versions, > modified for different projects from different people, that has > different compatibility level. And even, different versions compiled for > different CPU architectures among our cluster. > > I prefer to only rely $RTE_SDK to know where "everything is". I could > tell to my users to add something in their LD_LIBRARY_PATH, but I would > prefer to stick to only the standard RTE_SDK and RTE_TARGET.
You can install inside RTE_SDK. This is what the command I gave you to test do. Installation is just organizing files in a directory so it can be consumed. Did you read the commands I sent? It is installing in $(pwd)/myinstall. After install, RTE_SDK becomes $(pwd)/myinstall/share/dpdk. > >> 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. > > You know best... I still think make install is unnecessary in most cases > so I would not change the doc either... I say "make install" is a must and there is no reason no to do it. Please check the steps I wrote for you.
