[dpdk-dev] [PATCH 0/2] remove use of weak functions from libraries

Bruce Richardson bruce.richardson at intel.com
Tue May 28 10:06:27 CEST 2019


On Mon, May 27, 2019 at 04:57:15PM -0400, Aaron Conole wrote:
> Bruce Richardson <bruce.richardson at 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 at 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?
>
Funnily enough, I've no objections to that :-) 


More information about the dev mailing list