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

[Tom Barbette <barbette@kth.se>]

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.

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

Tom