[Bug libstdc++/126786] [libstdc++] Module fallback installs empty interface files but the manifest lists them
"redi at gcc dot gnu.org via Gcc-bugs" <[email protected]>
| Newsgroups | gmane.comp.gcc.bugs |
|---|---|
| Message-ID | <[email protected]/bugzilla/> |
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=126786
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
Last reconfirmed| |2026-08-17
Status|UNCONFIRMED |ASSIGNED
Target Milestone|--- |16.3
Ever confirmed|0 |1
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #1)
> The fallback should never be used, it only exists to avoid breaking
> bootstrap for targets where nobody is testing/using the std modules. If the
> fallback is being used, then that's the bug and that should be fixed.
To put this another way, if the fallback gets used, the std module is broken on
that target. And so the fact that you get cmake errors when trying to use the
std module is not surprising. You can't use it because it's broken.
I don't think we should bother making a fallback for broken targets more robust
so that you can use the broken 'std' module. Doing 'import std' isn't going to
magically start to work if we make the manifest more accurate.
We probably should install the original std.cc and std.compat.cc files though,
not the empty files. Users might be able to compile them with custom options,
even if compiling them as part of the GCC build failed.
So we should not do anything to change the manifests, we should just install
the original files.