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
