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 01DE5A057C; Fri, 27 Mar 2020 16:53:21 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id B40781C23A; Fri, 27 Mar 2020 16:53:20 +0100 (CET) Received: from smtp-3.sys.kth.se (smtp-3.sys.kth.se [130.237.48.192]) by dpdk.org (Postfix) with ESMTP id 5B0D81C239 for ; Fri, 27 Mar 2020 16:53:19 +0100 (CET) Received: from smtp-3.sys.kth.se (localhost.localdomain [127.0.0.1]) by smtp-3.sys.kth.se (Postfix) with ESMTP id 976C752C9; Fri, 27 Mar 2020 16:53:18 +0100 (CET) X-Virus-Scanned: by amavisd-new at kth.se Received: from smtp-3.sys.kth.se ([127.0.0.1]) by smtp-3.sys.kth.se (smtp-3.sys.kth.se [127.0.0.1]) (amavisd-new, port 10024) with LMTP id ZYbVXddl-6es; Fri, 27 Mar 2020 16:53:17 +0100 (CET) X-KTH-Auth: barbette [2a02:a03f:4070:7c00:9497:bf60:4477:6ee1] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1585324397; bh=iBWbGMuGwnGbUOLxGGzV4YV4u3OLoeeXq2NqOhDdYn4=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=edigo+md8ZcEwixNG6TObrCf0/T02pJWB9vVemCCqfCBH6wwP6m3Ro4w5UbSswhLy 1TX4xXmoO84tpmaSiVPZMNbs1No0+7pM1IQfOudP5PQBvKLFFmAGQetNUd+orhYtkd 2i9nBHXLcrJKKpK69UD2nymre4UVNetMRMJwIRuY= X-KTH-mail-from: barbette@kth.se Received: from [IPv6:2a02:a03f:4070:7c00:9497:bf60:4477:6ee1] (unknown [IPv6:2a02:a03f:4070:7c00:9497:bf60:4477:6ee1]) by smtp-3.sys.kth.se (Postfix) with ESMTPSA id D1FF032B8; Fri, 27 Mar 2020 16:53:16 +0100 (CET) To: Thomas Monjalon Cc: dev@dpdk.org, Matthew Hall References: <2838010.xgJ6IN8ObU@xps> <24030728-aa1c-d075-d644-c1f7dc7122b5@kth.se> <2812875.WAvfycf1tz@xps> From: Tom Barbette Message-ID: Date: Fri, 27 Mar 2020 16:53:15 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:68.0) Gecko/20100101 Thunderbird/68.6.0 MIME-Version: 1.0 In-Reply-To: <2812875.WAvfycf1tz@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: fr Content-Transfer-Encoding: 8bit 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" 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. > > >