https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121574
--- Comment #11 from shyeyian <shyeyian at petalmail dot com> --- I've made several PR to third party libraries on 'remove TU-local entities in order to modulize' as well. [boost.locale] https://github.com/boostorg/locale/pull/262 [boost.gil] https://github.com/boostorg/gil/pull/767 [fmt]: https://github.com/fmtlib/fmt/pull/4488 - Also fix gcc modulize. [Eigen]: https://gitlab.com/libeigen/eigen/-/merge_requests/1960 - Here const *Index* is TU-local but const *int* is not. As I proved Index to be always int, it implicitly fix gcc modulize as well. [beman.execution] https://github.com/bemanproject/execution/pull/183 But it is impossible for us to one-by-one create PR for all the third-party libraries and explain for the reason that 'only in g++ with modules, I met this compilation failure, and please remove your `static` TU-local declarations here'. Therefore, allowing developers to expose TU-local entities (with warnings and at their own risk) would be extremely helpful. Both Clang and MSVC already allow this behavior (without warnings). From my perspective, GCC’s approach—allowing it but issuing a warning is the most balanced and practical solution. --- You might think about other ways, like "we can write a tiny C++-parser which replaces every 'global static' in the included headers! Then, the code is strictly-standard!". I've tried it through 'clang-format' + python script, and, you see, clang-format itself showed a bug when formatting every header in Eigen. I simplified it and finally found the minimal reproducable scene. [clang-format first bug] https://github.com/llvm/llvm-project/issues/154683 After waiting for llvm maintainers to first time repair it, [clang-format second fix] https://github.com/llvm/llvm-project/pull/154787 - Down scroll the PR page. Which has finally been repaired in llvm-22 after several days (Thanks to llvm maintainers!). However, that only solves the first step of the problem. The real root cause lies in the fact that older versions of GCC simply disallow exposing TU-local entities. Instead of working around this restriction again and again, why not address the root cause directly? If GCC could tolerate TU-local exposure (while still issuing warnings), it would be a far better and more developer-friendly solution. --- Thank you! :)
