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

[Jan Beulich]

On 13.01.2026 18:57, Fangrui Song wrote:
> On Tue, Jan 13, 2026 at 8:44 AM Maciej W. Rozycki <macro@redhat.com> wrote:
>>
>> 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 appreciate that Maciej takes the efforts to implement features
> needed by --start-lib/--end-lib.
> While I cannot review these patches, I can share some perspective on
> why --start-lib/--end-lib is useful
> 
>>  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
> 
> Quoting the relevant parts from
> https://maskray.me/blog/2022-01-16-archives-and-start-lib
> 
> """
> Google investigated techniques to improve build speed. In 2008-03,
> Cary Coutant (then at Google) posted PATCH: Add support for "thin"
> archives on the binutils mailing list. Here is the key insight:
> 
> At other times, I've received requests from customers who are using
> archive libraries as intermediate collections of .o files during a
> build of a large project. In this usage model, the archives aren't
> intended for distribution outside that project; they're just used
> during the build. In these situations, the .o files will remain where
> they are in the build directories, and the copying of the files into
> the archive libraries is a waste of time and space -- useful only
> because the archive library serves as a useful collection mechanism to
> simplify the later link command.
> 
> [...]
> 
> If a.a contains b.o c.o, ld ... --start-lib b.o c.o --end-lib behaves
> exactly the same way as ld ... a.a.
> 
> The apparent pros of --start-lib over thin archives are:
> 
> * The build system can skip building archives. All files must be
> available to build the archive symbol table (to satisfy GNU linkers).
> GNU ar has the requirement even if you enable D (deterministic mode)
> and thin archives. In a distributed build system, this   adds a gather
> step before linking.
> 
> * We don't waste the archiver's time on building the thin archive
> symbol table. No regular and thin archive confusion.

Hmm, yes, but how much time are we talking about here? Surely a tiny
percentage of overall build time? Whether that's still meaningful in
terms of absolute time is of course less clear (as in principle it
could be thousands of objects).

Jan