From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.0 (2014-02-07) on aws-us-west-2-korg-lkml-1.web.codeaurora.org X-Spam-Level: X-Spam-Status: No, score=-4.0 required=3.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,SIGNED_OFF_BY,SPF_HELO_NONE,SPF_PASS,URIBL_BLOCKED autolearn=no autolearn_force=no version=3.4.0 Received: from mail.kernel.org (mail.kernel.org [198.145.29.99]) by smtp.lore.kernel.org (Postfix) with ESMTP id 62662C433DF for ; Wed, 1 Jul 2020 08:43:52 +0000 (UTC) Received: from dpdk.org (dpdk.org [92.243.14.124]) by mail.kernel.org (Postfix) with ESMTP id 08A6720747 for ; Wed, 1 Jul 2020 08:43:51 +0000 (UTC) DMARC-Filter: OpenDMARC Filter v1.3.2 mail.kernel.org 08A6720747 Authentication-Results: mail.kernel.org; dmarc=fail (p=none dis=none) header.from=intel.com Authentication-Results: mail.kernel.org; spf=pass smtp.mailfrom=dev-bounces@dpdk.org Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5809B1C1EE; Wed, 1 Jul 2020 10:43:51 +0200 (CEST) Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 6C8231C1E7 for ; Wed, 1 Jul 2020 10:43:49 +0200 (CEST) IronPort-SDR: AldagXrvU0jp1XWgl+05Aaf49gZXoQoPQwhT6zzZB7obGJy0PfI7IDG6WmfK3RFMn4ATyJYAYh xFdTuoN8qJeg== X-IronPort-AV: E=McAfee;i="6000,8403,9668"; a="134786123" X-IronPort-AV: E=Sophos;i="5.75,299,1589266800"; d="scan'208";a="134786123" X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 01 Jul 2020 01:43:48 -0700 IronPort-SDR: 8orDQWBrHaf1ifjjB7+DlO1dJYx1cNj5OByGIOKWXDVa2ePj6tS+5tMCOEzwV1jndq8lSKZ9Og 8yersuYq/y6A== X-IronPort-AV: E=Sophos;i="5.75,299,1589266800"; d="scan'208";a="455021110" Received: from mcarroll-mobl.ger.corp.intel.com (HELO bricha3-MOBL.ger.corp.intel.com) ([10.251.80.77]) by orsmga005-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-SHA; 01 Jul 2020 01:43:46 -0700 Date: Wed, 1 Jul 2020 09:43:43 +0100 From: Bruce Richardson To: Thomas Monjalon Cc: dev@dpdk.org, david.marchand@redhat.com, ktraynor@redhat.com, bluca@debian.org, sunil.pai.g@intel.com Message-ID: <20200701084343.GA595@bricha3-MOBL.ger.corp.intel.com> References: <20200429100831.398-1-bruce.richardson@intel.com> <20200630141433.818517-1-bruce.richardson@intel.com> <20200630141433.818517-6-bruce.richardson@intel.com> <12508772.kpFtruyFWe@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <12508772.kpFtruyFWe@thomas> Subject: Re: [dpdk-dev] [PATCH v3 5/7] build/pkg-config: output driver libs first for static build 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" On Wed, Jul 01, 2020 at 09:50:20AM +0200, Thomas Monjalon wrote: > 30/06/2020 16:14, Bruce Richardson: > > When calling pkg-config --static --libs, pkg-config will always output the > > regular libs first, and then the extra libs from libraries.private field, > > since the assumption is that those are additional dependencies for building > > statically that the .a files depend upon. > > > > However, for DPDK, we only link the driver files for static builds, and > > Sorry, I'm lost here. Why "only" driver files? My fault for poor word ordering. Should be rewritten as "link the driver files only for static builds". > > > those need to come *before* the regular libraries. > > Given whole libs are linked, is it really needed to have drivers first? If we are considering only static libs, then I suspect not, but to avoid having the shared libraries also linked into the static binaries they definitely need to come last, so they can be linked with as-needed i.e. skipped by the linker. > > > To get this result, we > > need two pkgconfig files for DPDK, one for the shared libs, and a second > > for the static libs and drivers, which depends upon the first. Using a > > dependency means that the shared libs are printed only after the > > libraries.private field rather than before. > > > > Without this patch, the linking works in DPDK because in all cases we > > specify the libraries after the drivers in the Libs.private line, ensuring > > that the references to the libs from the drivers can be resolved. The > > current output is therefore of the form, "(shared)libs, drivers, > > (static)libs", while after this patch the output is, "drivers, > > (static)libs, (shared)libs". The former case will not work if we use the > > --whole-archive flag on the static libs as it will lead to duplicate > > definitions due to some references having been previously resolved from the > > shared libraries. > > I'm completely lost. In which case we link both static and shared libs? > It will depend partially upon other linker flags used before the pkgconfig insert. We would be relying upon the user integrating this to explicitly pass in -Bstatic flag before putting the pkgconfig flags output. With the current config, we can't add that ourselves because to go first it would have to go (ironically) in the shared lib part of the pkg-config file. By splitting things into two, it allows the static libs to come before the shared ones, which gives us the ability to control things far better. > > By ensuring the shared libraries come last in the link > > link, this issue does not occur, as duplicate references when linking the > > shared libs will be ignored. > > > > Signed-off-by: Bruce Richardson > > Acked-by: Luca Boccassi > > Acked-by: Sunil Pai G > > >