[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:

> >> Overall I feel like the underlying idea of "file collections" (plus why /
> >> where / when it's useful) isn't explained sufficiently in the description.
> >> Maybe that would become more clear by reading the next patch, but I think
> >> the patch here would best be self-contained.
> > 
> >  I'm not sure what else can be added here.  The change heading already 
> > mentions that this is for the linker (I've now added "linker" for clarity 
> > in a reference to symbol resolution in the first sentence as well) and the 
> > description overall says that a collection of files supplied via a call to 
> > `bfd_openr_fake_archive' will be treated by the BFD linker as if they were 
> > archive members.
> > 
> >  It then goes on to explain some implementation details.
> > 
> >  If you find anything particularly unclear, then please point me there.
> 
> 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.

 I don't suppose you want me to explain here how archives work in a link 
as opposed to individual object files, as this is covered by our manual 
and/or various books, do you?  And also I don't think it's a good idea to 
set a usage policy by drawing potential use cases in a commit description.

 I maintain that the new API is sufficiently documented and, as I say, if 
you think it's missing a detail, then I'll be happy to fill it in, but I'm 
unaware of any such detail.

  Maciej