* [dpdk-dev] Impossible to build external application if user build DPDK with "make config" @ 2020-03-12 12:04 Tom Barbette 2020-03-27 9:14 ` Tom Barbette 0 siblings, 1 reply; 9+ messages in thread From: Tom Barbette @ 2020-03-12 12:04 UTC (permalink / raw) To: dev 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Impossible to build external application if user build DPDK with "make config" 2020-03-12 12:04 [dpdk-dev] Impossible to build external application if user build DPDK with "make config" Tom Barbette @ 2020-03-27 9:14 ` Tom Barbette 2020-03-27 10:35 ` Thomas Monjalon 0 siblings, 1 reply; 9+ messages in thread From: Tom Barbette @ 2020-03-27 9:14 UTC (permalink / raw) To: dev; +Cc: Matthew Hall, Thomas Monjalon 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Impossible to build external application if user build DPDK with "make config" 2020-03-27 9:14 ` Tom Barbette @ 2020-03-27 10:35 ` Thomas Monjalon 2020-03-27 12:35 ` Tom Barbette 0 siblings, 1 reply; 9+ messages in thread From: Thomas Monjalon @ 2020-03-27 10:35 UTC (permalink / raw) To: Tom Barbette; +Cc: dev, Matthew Hall 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? ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Impossible to build external application if user build DPDK with "make config" 2020-03-27 10:35 ` Thomas Monjalon @ 2020-03-27 12:35 ` Tom Barbette 2020-03-27 13:55 ` Thomas Monjalon 0 siblings, 1 reply; 9+ messages in thread From: Tom Barbette @ 2020-03-27 12:35 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev, Matthew Hall 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Impossible to build external application if user build DPDK with "make config" 2020-03-27 12:35 ` Tom Barbette @ 2020-03-27 13:55 ` Thomas Monjalon 2020-03-27 14:24 ` Tom Barbette 0 siblings, 1 reply; 9+ messages in thread From: Thomas Monjalon @ 2020-03-27 13:55 UTC (permalink / raw) To: Tom Barbette; +Cc: dev, Matthew Hall 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Impossible to build external application if user build DPDK with "make config" 2020-03-27 13:55 ` Thomas Monjalon @ 2020-03-27 14:24 ` Tom Barbette 2020-03-27 15:06 ` Thomas Monjalon 0 siblings, 1 reply; 9+ messages in thread From: Tom Barbette @ 2020-03-27 14:24 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev, Matthew Hall 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 ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Impossible to build external application if user build DPDK with "make config" 2020-03-27 14:24 ` Tom Barbette @ 2020-03-27 15:06 ` Thomas Monjalon 2020-03-27 15:53 ` Tom Barbette 0 siblings, 1 reply; 9+ messages in thread From: Thomas Monjalon @ 2020-03-27 15:06 UTC (permalink / raw) To: Tom Barbette; +Cc: dev, Matthew Hall 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Impossible to build external application if user build DPDK with "make config" 2020-03-27 15:06 ` Thomas Monjalon @ 2020-03-27 15:53 ` Tom Barbette 2020-03-27 22:40 ` Thomas Monjalon 0 siblings, 1 reply; 9+ messages in thread From: Tom Barbette @ 2020-03-27 15:53 UTC (permalink / raw) To: Thomas Monjalon; +Cc: dev, Matthew Hall 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. > > > ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: [dpdk-dev] Impossible to build external application if user build DPDK with "make config" 2020-03-27 15:53 ` Tom Barbette @ 2020-03-27 22:40 ` Thomas Monjalon 0 siblings, 0 replies; 9+ messages in thread From: Thomas Monjalon @ 2020-03-27 22:40 UTC (permalink / raw) To: Tom Barbette; +Cc: dev, Matthew Hall 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. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2020-03-27 22:40 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-03-12 12:04 [dpdk-dev] Impossible to build external application if user build DPDK with "make config" Tom Barbette 2020-03-27 9:14 ` Tom Barbette 2020-03-27 10:35 ` Thomas Monjalon 2020-03-27 12:35 ` Tom Barbette 2020-03-27 13:55 ` Thomas Monjalon 2020-03-27 14:24 ` Tom Barbette 2020-03-27 15:06 ` Thomas Monjalon 2020-03-27 15:53 ` Tom Barbette 2020-03-27 22:40 ` Thomas Monjalon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).