From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 9B24A2C66 for ; Mon, 19 Feb 2018 15:05:03 +0100 (CET) Received: from cpe-2606-a000-111b-40b7-640c-26a-4e16-9225.dyn6.twc.com ([2606:a000:111b:40b7:640c:26a:4e16:9225] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES256-SHA:256) (Exim 4.63) (envelope-from ) id 1enm3m-0003bQ-PG; Mon, 19 Feb 2018 09:05:01 -0500 Date: Mon, 19 Feb 2018 09:04:10 -0500 From: Neil Horman To: tom.barbette@uliege.be Cc: dev@dpdk.org Message-ID: <20180219140410.GA3527@hmswarspite.think-freely.org> References: <328301853.77122566.1519033179263.JavaMail.zimbra@uliege.be> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <328301853.77122566.1519033179263.JavaMail.zimbra@uliege.be> User-Agent: Mutt/1.9.2 (2017-12-15) X-Spam-Score: -2.9 (--) X-Spam-Status: No Subject: Re: [dpdk-dev] Linking with -ldpdk 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: , X-List-Received-Date: Mon, 19 Feb 2018 14:05:03 -0000 On Mon, Feb 19, 2018 at 10:39:39AM +0100, tom.barbette@uliege.be wrote: > Hi list, > > I found out that to staticly compile against DPDK using the combined lib, I needed all these options : > > -I${RTE_SDK}/${RTE_TARGET}/include -L${RTE_SDK}/${RTE_TARGET}/lib -Wl,--whole-archive -ldpdk -Wl,--no-whole-archive -lnuma -ldl -lpthread -lm -lmlx4 -lmlx5 -libverbs > > The whole-archive makes sense, as we need to embed drivers that wouldn't be found at linking time (failing to include it prevents port discovery). > However it leads to missing inclusion. That's why I added all the libs at the end of the line. The mlx4 libs particularly leads me to think that there must be a more programmatic way, portable accross versions of DPDK to find out which libraries referenced in DPDK I should include, right? Morveover if the DPDK user didn't include mlx4, it will fail to compile... > Thats really the problem with static linking, theres no built-in dependency tracking, the way the DT_NEEDED entries provide in dynamic linking. The build environment is responsible for understanding the libraries needed to resolve all the symbols that an application and its libraries require at compile time. In the case of the mlx drivers, I beleive there is an effort to break the symbol dependency by using the dlopen interface to resolve those symbols at run time, but the scope of that effort is strictly for the mellanox drivers. You still need to manually track the numa, pthreead, math, etc libraries. > What should I use? (the whole rte.extapp.mk DPDK build process is not an option as the build system is rather complex in this project) > I'd recommend building dpdk as a shared library. Then the DSO embodies the subordonate libraries that have to be loaded by the linker at run time, and you don't have to worry about it at all. You just have to link with -ldpdk (the shared build creates a linker script called dpdk.so that automagically pulls in all the component DSOs). > Or maybe some of these libraries should be included in the dpdk static lib? > Thats not a scalable solution. Some libraries don't have static versions that you can link to (or don't have versions that build commonly as such). And even if they do, determining if you need to link them is a bit of a trick. As Bruce notes, he's trying to use package-config to solve the problem, but that tool isnt meant for conditional compilation. > I use the last git version (but it's the same problem with previous ones). > > Thanks, > > Tom >