[PATCH v3 17/18] PR ld/24600: BFD: Add general linker support for fake archives

[Maciej W. Rozycki]

On Tue, 13 Jan 2026, Jan Beulich wrote:

> >> I can only repeat that I'm missing any information on when / where this is
> >> actually useful (and why using an archive in the same situation would be
> >> undesirable / impossible). Without such information, I fear I'm not feeling
> >> in the position to approve respective changes. (Which of course doesn't
> >> mean I would NAK them; another maintainer might still do the review and
> >> give their okay.)
> > 
> >  It's useful where the caller of `bfd_openr_fake_archive' wants to treat a 
> > collection of files as if they were an archive, in a link.
> 
> And what gets in the way of actually making them into an archive, when
> "as if an archive" is wanted?

 I don't know, especially given our support for thin archives (regular 
archives require so much extra storage space as the original copies of 
member files have already taken, and I suppose that could be an issue, but 
that's been already solved with thin archives).

 It seems an actually used feature however, given that unmaintained and 
deprecated GOLD already has it and I'm told the lack of this feature in 
BFD prevents GOLD from being dropped from binutils as some projects rely 
on this feature despite the obvious performance penalty.

 In PR ld/24600 Fangrui says:

> --start-lib gives following object files (before --end-lib) archive 
> semantics.  They are handy if you don't want to create archives for the 
> semantics.  Some build system makes use of this option as an optimization: 
> after changes of object files, no archives need updating.

(which is of course more about 18/18 rather than this change; and then 
obviously in the absence of a symbol map no thin archive needs an update 
anyway where any member has changed, as members are included there by 
reference only) and then:

> This option can sometimes be more useful than a thin archive.

 Fangrui, would you therefore please elaborate on what "more useful" 
exactly refers to here and why is it so important to have this feature? 

 From your write-up linked to the PR ISTM the only real advantage over a 
mapless thin archive is skipping an `ar' invocation (but the handling of 
this stuff in the GNU system has been largely solved by `libtool').

  Maciej