From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v3 3/6] mk: sort libraries when linking, move pmd libs to higher level Date: Mon, 13 Jun 2016 12:21:50 +0200 Message-ID: <2346375.5264sTWdP2@xps13> References: <1465564749-1405-1-git-send-email-thomas.monjalon@6wind.com> <3213594.AWeSi4j5H8@xps13> <575E8543.2080504@intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, Panu Matilainen , Christian Ehrhardt To: Ferruh Yigit Return-path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 526855586 for ; Mon, 13 Jun 2016 12:21:52 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id n184so71633078wmn.1 for ; Mon, 13 Jun 2016 03:21:52 -0700 (PDT) In-Reply-To: <575E8543.2080504@intel.com> List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 2016-06-13 11:04, Ferruh Yigit: > On 6/13/2016 10:29 AM, Thomas Monjalon wrote: > > 2016-06-10 19:32, Ferruh Yigit: > >> As stated in the comment: > >> Order is important: from higher level to lower level > >> > >> This is an attempt to make the layering order better respected. > >> > >> Limit scope of --whole-archive to pmd libraries > > > > Compared to the link order in the v2, you did two things: > > 1/ move PMDs to the first position > > 2/ restrict --whole-archive to PMDs only > > > > Having the PMDs first, helps the linker to get all the PMD dependencies > > in the static binary. Thus it seems we do not need --whole-archive > > for the PMD dependencies (ethdev, mbuf, etc). > > But, if an external PMD is loaded via dlopen, it is possible that it > > needs a symbol which was not used by the internal PMDs. So it will not > > be found in the statically linked binary. > > Let's take another example: if we disable the internal PMDs with their > > config options from the static build, and we decide to build them > > separately as DSOs. We won't be able to load them as plugins because > > they depend on symbols which won't be found in the static binary. > > So you want to keep all objects in final binary (used or unused) because > of the possibility that any plugin may use them. Yes > But what is the list to include here, whole dpdk?, -since we may not > know what API will plugin call. The list of the libraries candidates to be called from a driver can be discussed. The top layers like lpm or distributor should not be in this list I think. > What I am confused is --whole-archive only used when dpdk compiled as > static, if dpdk compiled as shared, each PMD should have proper > dependencies [1], and if external PMD compiled properly there shouldn't > be a problem. So do we have a case that dpdk compiled statically into > final binary but we still want to load some plugins dynamically? Yes a plugin can be loaded from a static binary. Breaking this feature would need a separate discussion and notices. > > To make it short, the PMDs must be considered as plugins. Therefore, we > > must not rely on their availability to link the required symbols in > > a static binary. > > To make sure the plugin loading will be always well achieved, we must > > link the static PMDs at the last position. > > I think this is not the issue of linking PMD's first or last, but > expanding --whole-archive to cover other libraries other than PMDs. Yes, linking PMD at the end is a way to force us to keep some libraries in --whole-archive. > > If you agree, I vote for the v2 of this patchset. > > If this is breaking something and best way to fix is not in external PMD > but in here, please feel free to go with v2. I don't see any other solution. But I'm sure we could discuss it more and/or improve it in the future.