From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: <dev-bounces@dpdk.org> Received: from dpdk.org (dpdk.org [92.243.14.124]) by dpdk.space (Postfix) with ESMTP id 97E34A045E for <public@inbox.dpdk.org>; Mon, 27 May 2019 22:57:24 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id D13E43DC; Mon, 27 May 2019 22:57:22 +0200 (CEST) Received: from mx1.redhat.com (mx1.redhat.com [209.132.183.28]) by dpdk.org (Postfix) with ESMTP id 6706CA3 for <dev@dpdk.org>; Mon, 27 May 2019 22:57:21 +0200 (CEST) Received: from smtp.corp.redhat.com (int-mx03.intmail.prod.int.phx2.redhat.com [10.5.11.13]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id 43E2AC057F3E; Mon, 27 May 2019 20:57:20 +0000 (UTC) Received: from dhcp-25.97.bos.redhat.com (ovpn-120-176.rdu2.redhat.com [10.10.120.176]) by smtp.corp.redhat.com (Postfix) with ESMTPS id C10DB608A4; Mon, 27 May 2019 20:57:16 +0000 (UTC) From: Aaron Conole <aconole@redhat.com> To: Bruce Richardson <bruce.richardson@intel.com> Cc: David Marchand <david.marchand@redhat.com>, "Ananyev\, Konstantin" <konstantin.ananyev@intel.com>, dev <dev@dpdk.org> References: <20190410134517.63896-1-bruce.richardson@intel.com> <CAJFAV8ysd541icrJGsPXf=eSLsaiNAy3v2KVpMRoj9==Vsrdvg@mail.gmail.com> <20190527154121.GA429@bricha3-MOBL.ger.corp.intel.com> Date: Mon, 27 May 2019 16:57:15 -0400 In-Reply-To: <20190527154121.GA429@bricha3-MOBL.ger.corp.intel.com> (Bruce Richardson's message of "Mon, 27 May 2019 16:41:21 +0100") Message-ID: <f7t7eab1uqc.fsf@dhcp-25.97.bos.redhat.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Scanned-By: MIMEDefang 2.79 on 10.5.11.13 X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16 (mx1.redhat.com [10.5.110.32]); Mon, 27 May 2019 20:57:20 +0000 (UTC) Subject: Re: [dpdk-dev] [PATCH 0/2] remove use of weak functions from libraries X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions <dev.dpdk.org> List-Unsubscribe: <https://mails.dpdk.org/options/dev>, <mailto:dev-request@dpdk.org?subject=unsubscribe> List-Archive: <http://mails.dpdk.org/archives/dev/> List-Post: <mailto:dev@dpdk.org> List-Help: <mailto:dev-request@dpdk.org?subject=help> List-Subscribe: <https://mails.dpdk.org/listinfo/dev>, <mailto:dev-request@dpdk.org?subject=subscribe> Errors-To: dev-bounces@dpdk.org Sender: "dev" <dev-bounces@dpdk.org> Bruce Richardson <bruce.richardson@intel.com> writes: > On Mon, May 27, 2019 at 04:13:53PM +0200, David Marchand wrote: >> Hello, >> On Wed, Apr 10, 2019 at 3:45 PM Bruce Richardson >> <[1]bruce.richardson@intel.com> wrote: >> >> Weak functions don't work well with static library builds as the >> linker >> always picks the first version of a function irrespective of whether >> it is >> weak or not. The solution to this is to use the "whole-archive" flag >> when >> linking, but this has the nasty side-effect that it causes the >> resulting >> binary to be larger than it needs to be. >> A further problem with this approach of using "whole-archive" is >> that one >> either needs to link all libraries with this flag or track what >> libraries >> need it or not - the latter being especially a problem for apps not >> using >> the DPDK build system itself (i.e. most apps not shipped with DPDK >> itself). >> For meson builds this information needs to make its way all the way >> through >> to the pkgconfig file generated - not a trivial undertaking. >> Thankfully, though, the use of weak functions is limited to use for >> multiple functions within a single library, meaning that when the >> lib is >> being built, the build system itself can know whether the "weak" >> function >> is needed or not. This allows us to change the weak function to a >> conditionally compiled regular function used in fallback case. This >> makes >> the need for "whole-archive" flag, and any special linking measures >> for the >> library, go away. >> [This set does not touch the drivers, only the libraries, since >> there are >> other special linker flags needed for drivers in general, making the >> problem less severe for driver .a files.] >> >> Was there something preventing this patchset from getting merged ? >> -- >> David Marchand >> > I believe Aaron Conole had some changes in the same area and was looking to > roll these changes into a bigger patchset of his. Aaron, can you please > confirm? Yes - Sorry the patches are in my queue. Maybe it just makes sense to merge these though? > /Bruce