From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ig0-f182.google.com (mail-ig0-f182.google.com [209.85.213.182]) by dpdk.org (Postfix) with ESMTP id 6FB8D5A96 for ; Wed, 18 Mar 2015 16:30:13 +0100 (CET) Received: by igcau2 with SMTP id au2so65942042igc.0 for ; Wed, 18 Mar 2015 08:30:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=g+n4D5xjFxePJqLBOSjOez2eECpLEHXLK0u6A4QnE9w=; b=C+JRjgYnycb3UcWJ5PY8n9n5v+GBJT6UBFx2xDhc6Uu6TVLg3jIdbz0f7sWOof0l7N lzSXNq+KHGKwo9ClT3gznavZkKZAoceaYP/KP8mCsxxO07F1cLEmNduGzc3E+4nj63aS aGDRM84ZqNYT7I624LUvaSpOhHSU46n8vh6ai3AVo1VIaFXcExkXU2s3ofHSKtTsZFqb yh3OEffsVigvFD/X3tdacnIzMhqBUHRzU+9rrNIKfHaLUS0QEL+7GGPKDR8yv+kGempQ 5Uq5EaDtFUtsHQUnSJzneEzotUP0dVgvWTRroTwxMdeuM4LQU+cBcIlxq3HneG22brDp i5FA== MIME-Version: 1.0 X-Received: by 10.51.17.40 with SMTP id gb8mr7894582igd.44.1426692612840; Wed, 18 Mar 2015 08:30:12 -0700 (PDT) Received: by 10.36.60.78 with HTTP; Wed, 18 Mar 2015 08:30:12 -0700 (PDT) In-Reply-To: <40763037.Qv1hPgBHv0@xps13> References: <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy@intel.com> <1426177681-16931-2-git-send-email-sergio.gonzalez.monroy@intel.com> <55096B86.7040303@intel.com> <40763037.Qv1hPgBHv0@xps13> Date: Wed, 18 Mar 2015 17:30:12 +0200 Message-ID: From: Stefan Puiu To: Thomas Monjalon Content-Type: text/plain; charset=UTF-8 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2 1/4] mk: Remove combined library and related options X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 18 Mar 2015 15:30:13 -0000 Hi, On Wed, Mar 18, 2015 at 2:59 PM, Thomas Monjalon wrote: > Hi Sergio, > > Thank you for explaining the situation. > > 2015-03-18 12:11, Gonzalez Monroy, Sergio: >> Given that the patch to remove combined libraries is not welcome, I'll >> try to explain the current situation so we can agree on the way forward. >> >> Currently we have build config option for shared libraries and combined >> libraries. Thus, this results in four possible combinations when >> building dpdk: >> - not combined static >> - not combined shared >> - combined static >> - combined shared >> >> The makefile rules/targets for combined are different than for not >> combined. Thus, we currently have two different files for >> archive/linking (rte.lib.mk and rte.sharelib.mk). >> >> Since having versioning, combined shared libraries build will be broken >> the moment we add a versioned API, as we do not have a global version >> map that we use when linking such library. >> Also in my opinion, we would want to prevent users linking against a >> combined libdpdk.so that may have different features built-in, with the >> corresponding debugging difficulties when users >> report different problems/errors. I think this would defeat many of the >> advantages of using shared libraries. >> >> By removing the combined library build option, we would simplify the >> build system with only two possible choices: >> - static >> - shared > > +1 > I believe that simplification is the way go. > >> This would allow us to remove one file (rte.sharelib.mk) and have a >> single file with archive/linking rules. >> >> For the convenience of linking against a single library instead of the >> multiple dpdk libraries, there are a few ways to go around it: >> - for combined static lib, we can either have a script to re-archive >> all libraries into a single/combined library (ie. extract all archives >> into one directory, the re-archive all objects into a combined library), >> or use a linker script (ie. GROUP ( -lrte_eal -lrte_malloc ... ) ). Would the linker script be provided in the repository or would it be the responsibility of people building against the DPDK? If I'd need to make a linker script with the list of libraries to link against, might as well put that list in my SConstruct / Makefile and be done with it. So the "write your own linker script" and "just deal with separate libraries" options don't seem that different to me. Let me ask you something - I understand your concerns about simplifying Makefiles and the concerns about versioning. How significant is the "separate libs" use case? And especially the "separate libs" in the current division of the code / libraries? I counted about ~30 libs in 1.8.0 under build/lib. Are there people using librte_eal without rte_malloc? Or rte_malloc without rte_mempool? I noticed that some examples I built ended up using --whole-archive -lrte_eal -lrte_etc.... To me, --whole-archive is one way of saying "we have lots of libraries with obscure dependencies", maybe reducing the number of libs might also be a way to make the combined lib unnecessary? I wouldn't bother with the combined lib if I had 3-4 libs to link against instead of the number of libs needed now. Just asking - obviously you guys are maintaining the code and know best, but I want to better understand the context from your side, as opposed to my (selfish) user perspective :). Thanks, Stefan. >> - for combined shared lib, we can use a linker script (ie. INPUT ( >> -lrte_eal -lrte_malloc ... AS_NEEDED -lrte_hash ...) ) or we could use a >> global version map (either somehow merging all independent version maps >> or maintaining a global version map). >> >> My preference would be to remove the combined libs as a build config >> option, then either add scripts to create those linker scripts or >> document it so users know how to create their own linker scripts. >> This would simplify the build process and still be able to provide the >> convenience of the combined library by using a linker script. >> >> Comments? > > You're right about the word convenience. > There are many ways to provide such convenience. > The first one is to simply use the DPDK makefiles which abstract linking problems. > If using DPDK framework is not an option, we can add new conveniences like > scripts or pkgconfig support. >