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 24934A057C; Fri, 27 Mar 2020 13:35:22 +0100 (CET) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 6E8AA1C197; Fri, 27 Mar 2020 13:35:21 +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 8AD301C137 for ; Fri, 27 Mar 2020 13:35:20 +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 29F9856A1; Fri, 27 Mar 2020 13:35:20 +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 nrod-mhTZwOD; Fri, 27 Mar 2020 13:35:18 +0100 (CET) X-KTH-Auth: barbette [2a02:a03f:4070:7c00:790a:1678:9957:28ed] DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kth.se; s=default; t=1585312518; bh=FNi7EGWr1oZucO0O29N9SazZxPeXrtwgXvgJXfLVTyI=; h=Subject:To:Cc:References:From:Date:In-Reply-To; b=YgemlLMo1BNxzXK/AqD9ZNFiwAcK99/2WLqnosaIRNChUo2tRKJtqkOeU4CRSC+Ax qI45xxECCgfCGY4xz3uq5KLK56c0+4boC/QLrmcWIeyn2fBr1V7PQKM7wjoqEik6Gx SrJsRl2ANHf7qxSD9aoIFK9Vq8OVNtGwjKvl5wbY= X-KTH-mail-from: barbette@kth.se Received: from [IPv6:2a02:a03f:4070:7c00:790a:1678:9957:28ed] (unknown [IPv6:2a02:a03f:4070:7c00:790a:1678:9957:28ed]) by smtp-3.sys.kth.se (Postfix) with ESMTPSA id CEAA85794; Fri, 27 Mar 2020 13:35:17 +0100 (CET) To: Thomas Monjalon Cc: dev@dpdk.org, Matthew Hall References: <83f48ac2-cf68-dc19-dc6b-d775e0b3de4e@kth.se> <1935321.K71DO8KEF6@xps> From: Tom Barbette Message-ID: <8876096d-45e3-7ab4-d7ea-0364eec0c0e4@kth.se> Date: Fri, 27 Mar 2020 13:35:16 +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: <1935321.K71DO8KEF6@xps> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US 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 à 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