On Thu, May 23, 2024 at 9:13 AM Daniel Ruoso via SG15 <sg15_at_[hidden]>
wrote:

> On Thu, May 23, 2024, 10:27 Chuanqi Xu <chuanqi.xcq_at_[hidden]>
> wrote:
>
>> Yes, I personally agree. But my question actually is, there are library
>> vendors don't buy it. For example, the libc++ developers say no explicitly.
>>
>
> In that case we need a proposal on how to annotate, in the code of the
> importable unit, that the importing unit must generate weak versions of the
> symbols that would otherwise be provided by the library
>
> Trying to handle this only in the build system is a really bad idea, IMHO.
>
> Daniel
>

Yes, to support "interface only" modules we need some syntax attached to
the module declaration. The next question is does that mean that only the
compiler generated symbols are weak? Or that even strong definitions
belonging to the module are made weak?

There's also two different ways to handle this. One is that you can have
multiple object files for an interface unit in a single program, but you
only need one per build environment. The second is that every TU that
imports (transitively) that interface unit needs to emit all used symbols
into its object file. The second is terrible and brings us back to headers
in terms of codegen cost. I'm not sure if CMake can do the first option
though. It would be very nice to not support the second option.

- Michael Spencer