[RFC] Move static archive dependencies into ld

[Howard Chu]

Michael Matz via Binutils wrote:
> Hello,
> 
> this is an RFC for now.  When met with some acceptance I'll cobble up a 
> similar thing for gold as well and then make the libdep.so plugin only 
> emit a warning message that its functionality is obsoleted and moved 
> into ld itself.  As Cary put it back in 2020 when the plugin was added:
> 
> ( https://sourceware.org/pipermail/binutils/2020-December/114536.html )
> 
> "Did I miss any discussion about whether this feature should/could be
> implemented directly in the linkers, rather than via a plugin? I
> wouldn't be opposed to it."

I'm all for it. I went the plugin route initially because it seemed the
easiest way to get the feature written and accepted but I agree with you,
it'd be much more useful if it was implicitly supported by default.
> 
> I pretty much think that yes, the functionality absolutely needs to be in 
> the linker itself, not in a plugin, at least if we want to see some use of 
> it in the real world.  Amusingly I was triggered to look into this by 
> libbfd itself:  Recently it got a dependency to libsframe and when 
> shipping only static archives to build against (which we as distro 
> consciously do) that leads to build errors in various 3rdparty packages 
> wanting to link against libbfd (no matter how bad an idea that is).  Now, 
> adding a '-plugin $magicdir/libdep.so' to the build flags of each such 
> package is no better than just adding '-lsframe' in each case, so the 
> plugin really doesn't help anything.  Had the functionality already been 
> in the linker itself we could have just added 
> "--record-libdeps='-lsframe'" when building libbfd.a and be done with it.
> 
> So, let's try to prepare for the future and at least now make ld interpret 
> such dependencies on its own.
> 
> So, what do people think?
> 
> 
> Ciao,
> Michael.
> 
> ---------------------------------------
> 
> needing a plugin to interpret static archive dependencies (as added
> by 'ar --record-libdeps') effectively means they are unused.
> Which is too bad, because they are actually useful.  So implement
> them in ld itself.



-- 
  -- Howard Chu
  CTO, Symas Corp.           http://www.symas.com
  Director, Highland Sun     http://highlandsun.com/hyc/
  Chief Architect, OpenLDAP  http://www.openldap.org/project/