From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wg0-f52.google.com (mail-wg0-f52.google.com [74.125.82.52]) by dpdk.org (Postfix) with ESMTP id 75AF358CB for ; Thu, 29 Jan 2015 18:02:54 +0100 (CET) Received: by mail-wg0-f52.google.com with SMTP id y19so23688925wgg.11 for ; Thu, 29 Jan 2015 09:02:54 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:cc:subject:date:message-id:organization :user-agent:in-reply-to:references:mime-version :content-transfer-encoding:content-type; bh=AOKmEujbJ8mHg8QdOfoCwIiIBlTQqlytE5rNSAQbQZE=; b=HikGuLqOMLFmyZcN3ItQHH2znZxQ1Q0Ox7oFsJL3bU0/WL2VBfv1CJs/010ULUMCLR TlO+6uybu3uFkQ1tuymxHJKbE17h685M5pckCdt0kMTEvaCZRbA0qbSpAJ3kxNt2lURI 2u19n2EPZ6eLrhEB1Fbhs4IBkt1jVnk4U0Er09QVGuC8Ou0Q6gazbi10Eb8FyLgLXV8V N+T/zQXYsIBaO/xHZfQRKh3QlnMriRkY1qNVKc5akWmZCQ+JtVf9NoR8c5PRNM80Ufgh znxaTwNXfoeNh4qyROchQfjz14/3bKLZWbomUH3ylYtSQHPU1Vj5tZxeCYmt/Egq7L7O vgPQ== X-Gm-Message-State: ALoCoQnf+7t1SN19TqgLsq1Y6jzs82+ngdGEc1XgFkQOYKHo311pNe7/Q4j9oic4YA7rGIhB+xr3 X-Received: by 10.194.234.40 with SMTP id ub8mr3213715wjc.100.1422550974345; Thu, 29 Jan 2015 09:02:54 -0800 (PST) Received: from xps13.localnet (136-92-190-109.dsl.ovh.fr. [109.190.92.136]) by mx.google.com with ESMTPSA id e11sm11226481wjx.1.2015.01.29.09.02.53 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jan 2015 09:02:53 -0800 (PST) From: Thomas Monjalon To: Neil Horman Date: Thu, 29 Jan 2015 18:02:28 +0100 Message-ID: <6409263.pK80EifcFX@xps13> Organization: 6WIND User-Agent: KMail/4.14.4 (Linux/3.18.4-1-ARCH; KDE/4.14.4; x86_64; ; ) In-Reply-To: <20150129163859.GE1999@hmsreliant.think-freely.org> References: <1422544811-26385-1-git-send-email-sergio.gonzalez.monroy@intel.com> <20150129163859.GE1999@hmsreliant.think-freely.org> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Cc: dev@dpdk.org Subject: Re: [dpdk-dev] [PATCH 0/8] Improve build process 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: Thu, 29 Jan 2015 17:02:54 -0000 2015-01-29 11:38, Neil Horman: > On Thu, Jan 29, 2015 at 03:20:03PM +0000, Sergio Gonzalez Monroy wrote: > > This patch series improves the DPDK build system mostly for shared > > libraries (and a few nits for static libraries) with the following goals: > > - Create a library containing core DPDK libraries (librte_eal, > > librte_malloc, librte_mempool, librte_mbuf and librte_ring). > > The idea of core libraries is to group those libraries that are > > always required (and have interdependencies) for any DPDK application. > > - Remove config option to build a combined library. > > - For shared libraries, explicitly link against dependant > > libraries (adding entries to DT_NEEDED). > > - Update app linking flags for static/shared DPDK libs. > > > > Sergio Gonzalez Monroy (8): > > mk: remove combined library and related options > > core: create new librte_core > > mk: new corelib makefile > > lib: update DEPDIRS variable > > lib: set LDLIBS for each library > > mk: use LDLIBS when linking shared libraries > > mk: update LDLIBS for app building > > mk: add -lpthread to linuxapp EXECENV_LDLIBS > > > Something occured to me thinking about this patch set. I noticed recently that > different rules are used to build the shared combined lib from the individual > shared objects. The implication here is that linker options specified in > individual make files (like the LIBABIVER and EXPORT_MAP options in my ABI > versioning script) get ignored, which is bad. Any other file specific linker > options (like _LDFLAGS specified in individual library makefiles are > getting dropped for the combined lib. > > It seems like it would be better if the combined libs were manufactured as > linker scripts themselves (textfiles that used linker directives to include > individual libraries under the covers (see /lib64/libc.so for an example). > > The disadvantage of such an approach are fairly minimal. With such a combined > library, you still need to install individual libraries, but for applications > that wish to link and run against a single dpdk library will still work just as > they currently do, you can link to just a single library. > > The advantage is clear however. By following a linker script aproach, objects > build as separate libraries are built exactly the same way, using the same rules > with the same options. It reduces the dpdk build environment size and > complexity, and reduces the opportunity for bugs to creep in from forgetting to > add build options to multiple locations. It also provides a more granular > approach for grouping files. Creating a dpdk core library becomes a matter of > creating a one line linker script named libdpdk_core.so, rather than re-arraning > sections of the build system. > > Thoughts? Neil, it seems to be a good idea. I like the idea of making things simpler ;) -- Thomas