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

[Tom Barbette]

Le 27/03/2020 à 16:06, Thomas Monjalon a écrit :
> 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.

Yes yes and I tried it as I said, leading to this lib problem. Still 
needs to ask the user to modify LD_LIBRARY_PATH to basically point it to 
$RTE_SDK/../../lib. I would have wanted to avoid that third one, but okay.

> 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.
Ok. Maybe add it to the quick steps then? Also the menu does not install 
"with T defined and DESTDIR undefined" and I always used that, which may 
have led me to believe make install was not really part of the process.

> Please check the steps I wrote for you.
> 
> 
>