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

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

[Tom Barbette]

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.

Thanks!

Tom

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

[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.
> 
> Thanks!
> 
> Tom

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

[Thomas Monjalon]

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?

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

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

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


Thanks,
Tom

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

[Thomas Monjalon]

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.

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

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

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

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

[Thomas Monjalon]

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.

Re: [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.
> 
> 
> 

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

[Thomas Monjalon]

27/03/2020 16:53, 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.

I understand.
LD_LIBRARY_PATH requirement is standard when linking with a library
which is not in a standard directory.

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

"make install T=" is an old method for compiling.
The real install process does not involve T=.
I will try to make all these steps more clear.

> > Please check the steps I wrote for you.