F
@john-0 Interessanterweise hatte ich gerade beim Bauen von GCC 16.1.0 exakt dasselbe Problem (Konflikt mit __mbstate_t). Die Ursache bei mir war allerdings, dass ich noch ein #include <meta> in einer meiner Quellcode-Dateien hatte aus einer Zeit, wo std::meta noch nicht in das std-Modul integriert war. Dabei war es übrigens egal, dass es vor dem import std; stand. in der alten Entwicklungsversion hat das noch so funktioniert, mit GCC 16.1.0 allerdings nicht mehr.
Stell auf jeden Fall sicher, dass du keine Header der Standardbibliothek mit #include einbindest, wenn du import std; verwendest. Ich habe auch in irgendwelchen Bug-Reports gelesen, dass das zu kombinieren nicht funktioniert. Da gibt's auf jeden Fall noch einiges, das im argen liegt beim std-Modul. Ich hab grad auch noch einen Bug gemeldet, der allerdings nicht direkt mit diesem Problem zu tun hat.
Mein Eindruck ist, dass das Modul nur wirklich gut mit der GCC-Standardkonfiguration funktioniert. Wenn man da irgendwas spezielles konfiguriert, läuft da noch eine Menge vor die Wand ... aber das ist bei dir denke ich schon eher "Standard", während ich an einer Runtime für DOS-Retroprogrammierung mit modernem C++ bastele. Da stoße ich doch recht häufig auf Dinge, die nicht so recht wollen. Runtime-Startup-Code, der vor der main() läuft und der in C++26 mit Reflection und Modulen programmiert wurde, ist wahrscheinlich auch ein etwas weniger "ausgetretener Pfad"
Kleine spaßige Anekdote am Rande: Meine Runtime ist grad in einem Zustand, wo ich einiges umgebaut habe und die main() noch gar nicht aufrufe. Das hat dazu geführt, dass beim Bauen der neuen GCC 16.1.0-Toolchain alle "Link-Tests" durchgegangen sind. Buildsysteme wie Autotools oder CMake testen ob Bibliotheksfunktionen existieren, indem sie ein Programm kompilieren, dass die entsprechende Funktion benutzt und schließen dann aus einem Linker-Fehler, dass die Funktion nicht existiert. Nun habe ich allerdings die Toolchain so konfiguriert, dass Compiler und Linker aggressiv allen Code eliminieren, der nicht aufgerufen wird (für möglichst kleine Binaries). So auch die main()-Funktion, wo der eigentliche Test der Funktion stattfindet. Resultat: Buildsysteme glauben, dass ALLE getesteten Funktionen existieren, was dann natürlich später gnadenlos vor die Wand läuft ... habe main nun im Linker-Skript explizit so angegeben, dass sie nicht "garbage-collected" wird, damit sowas nicht mehr vorkommt während ich da an Innereien herumbastele.
