On Tuesday, 22 December 2020 01:59:01 -03 kh via Std-Proposals wrote:
> I don't think it is necessary to put "libraries" into the standard.
> This was only mentioned as a practical description of the problem.
>
> My proposed solutions might be difficult or impossible to implement.
> Especially my second approach is irreconcilable with the current
> linker architecture as we don't have the necessary information
> available in that stage.

Indeed. Like I said, you need to change the way linkers work with static
libraries, something that has barely changed in the last 35 years.

> However, my first proposed solution (the extra attribute) is more
> viable. It would *only* require to put some kind of flag inside the
> object/library file for that symbol, that prevents the linker from
> removing it.

It's not being removed. That's not how linkers work.

It wasn't added in the first place. You need to make it be added, despite
providing no unresolved symbol that the current build needs. THAT is what you
need to change in linkers.

> gcc/ld even has some kind of support for this. "--whole-archive"
> enables this behavior on a per-file basis. I don't think It would be
> impossible to change that to a per-symbol basis.
>
> gcc also has "__attribute__((used))", which sadly only works on functions.

That's not "support for this". That's a workaround, forcing the entire library
to be added to your build, whether you need portions of it or not. You get a
much bigger binary as a result.

Anyway, I don't think this is a standard discussion, even if you propose an
attribute. First you need to talk to the four major linker implementations
(binutils, LLVM, MSVC and Apple) and see if they would consider a solution to
mark .o files inside static libraries as needed regardless of whether they
were actually needed.

-- 
Thiago Macieira - thiago (AT) macieira.info - thiago (AT) kde.org
   Software Architect - Intel DPG Cloud Engineering