UCRT has already resolved the issue by removing internal linkage, and the direction for the Clang headers is the same. GCC's intrinsic headers do not use internal linkage, and are the same as MSVC's, so they do not have this problem. The issue exists in Clang and UCRT because it added unnecessary static, just as has happened with some C++ libraries. Therefore, at least from a C++ perspective, removing static is the direction.


________________________________
From: Arthur O'Dwyer <arthur.j.odwyer_at_gmail.com>
Sent: Monday, June 22, 2026 22:09
To: Yexuan Xiao <bizwen_at_[hidden]>
Cc: Std-Proposals <std-proposals_at_lists.isocpp.org>
Subject: Re: [std-proposals] Proposal: Deprecate namespace-scope declarations that are declared both static and inline

On Mon, Jun 22, 2026 at 9:22 AM Yexuan Xiao <bizwen_at_[hidden]<mailto:bizwen_at_[hidden]>> wrote:
Of course I know that both anonymous namespaces and static are used for internal linkage, and that modules haven't changed anything about that. I don't know why you brought up anonymous namespace. I never mentioned it, because all the problematic code I encountered uses the static keyword. I forgot to include the issue URL when writing the email, you can take a look at https://github.com/llvm/llvm-project/issues/195661 and https://github.com/microsoft/STL/pull/5805.

Ah, I'd call that mainly a vendor issue with Modules, then: people are reporting to the compiler vendor that their Modules mode cannot actually compile (1) Boost or (2) their own STL.
https://github.com/llvm/llvm-project/issues/195661#issuecomment-4639344010 in particular sketches a potential (solution/hack) being considered by the Clang folks, to enable Modules to work with these existing codebases. I think that's a reasonable direction. What is certainly un-reasonable is to imagine that every existing codebase in the world will start avoiding `static inline` merely in order to work around open compiler issues related to Modules mode (which these existing codebases generally don't care about).

Jan Kokemüller wrote<https://github.com/llvm/llvm-project/issues/195661#issuecomment-4639344010>:
While removing static for those inline functions would be the "proper" fix (at least when compiling for C++), I think the compiler should handle this somehow, since using static inline for inline helper functions is such a common idiom in C. Exposing<https://eel.is/c++draft/basic.link#14> those functions is not really avoidable. For example, Boost::unordered uses the SSE intrinsics internally, but technically exposes them since it's all templates. For a C++ library to handle this correctly according to the standard, it must wrap all static inline functions in some kind of "wrapping layer", and then use that. But nobody does this, and it's likely that most C++ library authors are not even aware of this problem since it all "just works" when using headers.
Maybe something like this could work:

  * special case static inline functions that live in the global namespace and in the global module fragment
  * when compiling a module unit, give these functions module linkage (similar to the initializer symbol)

Other compiler vendors might try to solve the problem in other ways. But eventually one-or-more of them will solve it and then we can talk about standardizing existing practice. Or, technically, if they all give up on solving it, I guess we might finally agree that "Modules has failed" — but that seems highly unlikely to me, politically speaking.

Is there a corresponding GCC bug report, too?
Have you talked to Chuanqi Xu and/or Jan Kokemüller about the issue?

–Arthur