From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 73CADA057C; Fri, 27 Mar 2020 23:40:17 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 588361C121; Fri, 27 Mar 2020 23:40:16 +0100 (CET) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by dpdk.org (Postfix) with ESMTP id 8FF4C1C11D for ; Fri, 27 Mar 2020 23:40:14 +0100 (CET) Received: from compute7.internal (compute7.nyi.internal [10.202.2.47]) by mailout.nyi.internal (Postfix) with ESMTP id 275BF5C037B; Fri, 27 Mar 2020 18:40:14 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute7.internal (MEProxy); Fri, 27 Mar 2020 18:40:14 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=mesmtp; bh=JSB+mDQMtM0wUQcjhwyHh63ySKANQL4GfH2VHh1fU6w=; b=Pj7YyvOGN+48 /wreE7ODagOyjLcpU3vQOxdNX/1v1uCoQBG7c5Brhxn/VrOwR+HXCPHAQ8cF5+Wy UGaJ2SSq3l9eLbRAmwOZZ/wHfWCQFNivMy2YZCYkM9si5jRFP5QnDqScYPfPlSH6 +2nMa8+3If6dDkzMfcozF7g6Ch509kE= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm2; bh=JSB+mDQMtM0wUQcjhwyHh63ySKANQL4GfH2VHh1fU 6w=; b=HLJH0gxdw455RB3zA7pZkl7JN0ydf5w65yPXPoanmYxWBWak8NnNeUsy7 sF0XUUOigu6YUO5aHwwr1/FBUcvPFm74jfb0XV3zrY5BZZOpHw68bAf0gYj3klF5 wEnkTlQX9ysRXJMKxs9so88i8xmuwcT0+wUrhZIIRRn61yzrKe0kYxHneIF0zPHf HvlxYpk6rgozoO/bPdlTPms8OiTpcdffvaPAzvHzU5VvZ5/6ZTRaN7hJk+jNDuZY Lesa4dSFQnHcdftUjqwAgdJwiPGZM+y7oTKpcDDtv1AiV1AvsG9GVR0E+VBDgL2+ l+xIVQfCanYnr+Q7FiFnJ5WH5lNdA== X-ME-Sender: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedugedrudehledgudeiudcutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthhqredttddtudenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ffohhmrghinhepughpughkrdhorhhgpdgvgihtvhgrrhhsrdhmkhenucfkphepjeejrddu feegrddvtdefrddukeegnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrghmpehmrg hilhhfrhhomhepthhhohhmrghssehmohhnjhgrlhhonhdrnhgvth X-ME-Proxy: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 23EE7306C3A3; Fri, 27 Mar 2020 18:40:13 -0400 (EDT) From: Thomas Monjalon To: Tom Barbette Cc: dev@dpdk.org, Matthew Hall Date: Fri, 27 Mar 2020 23:40:12 +0100 Message-ID: <2164844.22IY78Rhhi@xps> In-Reply-To: References: <2812875.WAvfycf1tz@xps> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="iso-8859-1" Subject: Re: [dpdk-dev] Impossible to build external application if user build DPDK with "make config" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 27/03/2020 16:53, Tom Barbette: > Le 27/03/2020 =E0 16:06, Thomas Monjalon a =E9crit : > > 27/03/2020 15:24, Tom Barbette: > >> Le 27/03/2020 =E0 14:55, Thomas Monjalon a =E9crit : > >>> 27/03/2020 13:35, Tom Barbette: > >>>> Le 27/03/2020 =E0 11:35, Thomas Monjalon a =E9crit : > >>>>> 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 =E0 13:04, Tom Barbette a =E9crit : > >>>>>>> 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 somethin= g more > >>>>>>> standard that allows to build with external apps (eg use the menu= or > >>>>>>> propose "make config T=3Dx86_64-native-linuxapp-gcc > >>>>>>> O=3Dx86_64-native-linuxapp-gcc" instead). It's much easier for ex= ternal > >>>>>>> apps maintainer to refer to the DPDK tutorial for DPDK installati= on. > >>>>> > >>>>> I don't understand the issue. > >>>>> First of all, the external application should link an installed DPD= K. > >>>>> 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=3Dx86_64-native-linux-gcc O=3Dmybuild > >>>>> > >>>>> 2/ make -j4 O=3Dmybuild > >>>>> > >>>>> 3/ make install O=3Dmybuild DESTDIR=3Dmyinstall prefix=3D > >>>>> > >>>>> 4/ RTE_SDK=3D$(pwd)/myinstall/share/dpdk RTE_TARGET=3Dx86_64-native= =2Dlinux-gcc make -C myapp > >>>>> > >>>>> Please can you confirm it works? > >>>>> > >>>>> > >>>> > >>>> I don't think it is usual to link against an "installed" DPDK, actua= lly. > >>>> 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 me= nu > >>>> 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 coul= d 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 version= s, > >> modified for different projects from different people, that has > >> different compatibility level. And even, different versions compiled f= or > >> 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. > >=20 > > 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 consu= med. > > Did you read the commands I sent? It is installing in $(pwd)/myinstall. >=20 > Yes yes and I tried it as I said, leading to this lib problem. Still=20 > needs to ask the user to modify LD_LIBRARY_PATH to basically point it to= =20 > $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. > >=20 > >>>> Making RTE_SDK_BIN a ?=3D instead of a :=3D 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 propos= ed > >>>> because I'm really not sure people "install" DPDK... > >>> > >>> The correct method is installing the library and using standard envir= onment 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 cas= es > >> so I would not change the doc either... > >=20 > > 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= =20 > "with T defined and DESTDIR undefined" and I always used that, which may= =20 > have led me to believe make install was not really part of the process. "make install T=3D" is an old method for compiling. The real install process does not involve T=3D. I will try to make all these steps more clear. > > Please check the steps I wrote for you.