GCC 15.1.0 und Modules

*john 0

Es gibt eine neuere GCC Version 15.1.0. Mit dieser lässt sich nun import std; nutzen. Allerdings muss man weiterhin das Module selbst übersetzen. Das ganze Prozedere hat sich gegenüber 14.x.0 auch noch verändert, so dass man wieder die Makefiles anpassen muss. Nun sind die Bezeichner aus cstdlib auch wirklich im Namensraum std.

Das Standardmodul findet sich in include/c++/15.1.0/bits und muss selbst übersetzt werden.

g++-15 -std=c++20 -fmodules -c /opt/gcc-15.1.0/include/c++/15.1.0/bits/std.cc

Das Ergebnis liegt dann unter gcm.cache/std.gcm, und man kann es mit import std; nutzen, da der Compiler es selbst findet, braucht man keinen Pfad mehr anzuhängen wie das noch mit dem Modulisierten Headerfiles bei GCC 14.1.0 der Fall war.

Wichtig ist noch, dass man noch immer das Übersetzen von Sourcecode mit Module-Syntax mit der Option -fmodules aktivieren muss. Das -ts der 14.x.0 Version entfällt.

Finnegan

@john-0 Cool, danke für die Info. Hatte noch gar nicht gesehen, dass überhaupt schon die 15 raus ist.

Ich kann mir gut vorstellen, dass es für die .gcm-Dateien auch ein zentrales Verzeichnis in dem Baum gibt, in dem die GCC Binaries liegen. GCC-interne Bibliotheken werden z.B. u.a. in <gcc-bin>/../lib/gcc/<target-triple>/<gcc-version> gesucht. Da müsste man mal schauen, ob das auch für Module zutrifft.

Auch muss man, besonders wenn man GCC z.B. für Windows baut ohnehin jede Menge Anpassungen über eigene Build-Skripte machen, damit das Ganze läuft (dieser Moloch von GCC-Autotools-Projekt macht meiner Erfahrung nach eh nie exakt das, was man möchte, aber das dann auch für nen Motorola 68k ). Daher sehe ich es als Aufgabe der Entwickler, welche die GCC-Distribution zusammenstellen, das so zusammenzupacken, dass es "Out of the Box" funktioniert. Daher danke für den Hinweis, da hätte ich bestimmt ne Weile rumgesucht

Ich muss allerdings auch sagen, dass ich GCC auch unter Linux stets als "portablen" Cross Compiler mit statischen Abhängigkeiten baue, den man in ein beliebiges Verzeichnis (und auch auf ein anderes System) installieren kann, daher oft eigene Anpassungen. Einen "System-Compiler" baue ich nie, den belasse ich so wie er von der Linux-Distribution kommt. Daher mache ich eh nie "configure; make" sondern habe immer noch ein eigenes Build-Skript drumherum.

*john 0

@Finnegan sagte in GCC 15.1.0 und Modules:

@john-0 Cool, danke für die Info. Hatte noch gar nicht gesehen, dass überhaupt schon die 15 raus ist.

Da müsste man mal schauen, ob das auch für Module zutrifft.

Nein, es findet sich keinerlei .gcm Datei in der GCC Installation.

Auch muss man, besonders wenn man GCC z.B. für Windows baut ohnehin jede Menge Anpassungen über eigene Build-Skripte machen, damit das Ganze läuft (dieser Moloch von GCC-Autotools-Projekt macht meiner Erfahrung nach eh nie exakt das, was man möchte, aber das dann auch für nen Motorola 68k ). Daher sehe ich es als Aufgabe der Entwickler, welche die GCC-Distribution zusammenstellen, das so zusammenzupacken, dass es "Out of the Box" funktioniert. Daher danke für den Hinweis, da hätte ich bestimmt ne Weile rumgesucht

Ich mag die GNU autoconfig Skripte als Nutzer lieber als etwa Projekte, die mit cmake gebaut werden, da man nicht zuerst die Doku für Standard Sachen lesen muss. Bei komplizierteren Dingen kommt man da meist trotzdem nicht herum.

Den GCC 15.1.0 nur für Linux zu bauen ist ein simpler Prozess. Im großen ganzen muss man nur das Verzeichnis angeben, wohin der Compiler installiert werden soll, ein Suffix für die Kommandos und dann schränke ich die Auswahl an Sprachen ein (Ada, C, C++ und Fortran), die ich die anderen nicht in der neusten Version auf dem System brauche. Dann ein make bootstrap.

Die Crosscompiler z.B. für m68k muss man unter Ubuntu nicht selbst bauen, die werden mit der Distribution ausgeliefert. Den Grund weshalb ich den GCC selbst baue ist, dass ich eben die neuste Version nutzen will, um die Features der neuen Standards ausprobieren zu können.

Ich muss allerdings auch sagen, dass ich GCC auch unter Linux stets als "portablen" Cross Compiler mit statischen Abhängigkeiten baue, den man in ein beliebiges Verzeichnis (und auch auf ein anderes System) installieren kann, daher oft eigene Anpassungen. Einen "System-Compiler" baue ich nie, den belasse ich so wie er von der Linux-Distribution kommt. Daher mache ich eh nie "configure; make" sondern habe immer noch ein eigenes Build-Skript drumherum.

Für meine Zwecke reicht ein

../gcc-15.1.0/configure --prefix=/opt/gcc-15.1.0 --program-suffix=-15 --enable-threads --enable-tls --enable-bootstrap --disable-multilib --enable-languages=ada,c,c++,fortran,lto,m2

aus. Allerdings baue ich aus alter Gewohnheit den Compiler mit make bootstrap, so dass das fertige Produkt schon mit dem neuen Compiler gebaut wird, und nicht mit dem alten Compiler.

Finnegan

@john-0 sagte in GCC 15.1.0 und Modules:

@Finnegan sagte in GCC 15.1.0 und Modules:

@john-0 Cool, danke für die Info. Hatte noch gar nicht gesehen, dass überhaupt schon die 15 raus ist.

Da müsste man mal schauen, ob das auch für Module zutrifft.

Nein, es findet sich keinerlei .gcm Datei in der GCC Installation.

Ich meinte damit die Standardverzeichnisse, in denen der Compiler nach den passenden .gcm-Dateien sucht (sowas wie Standard-Library/Include-Verzeichnisse). Das wird hoffentlich nicht nur ./gcm_cache sein

Für meine Zwecke reicht ein

../gcc-15.1.0/configure --prefix=/opt/gcc-15.1.0 --program-suffix=-15 --enable-threads --enable-tls --enable-bootstrap --disable-multilib --enable-languages=ada,c,c++,fortran,lto,m2

Ja, ich dachte mir schon sowas. Das ist auch der gut ausgetretene "Standardpfad". Wenn man von dem abweicht, läuft man häufiger auf diverse Probleme, die ein eigenes Skript drumherum notwendig machen. So z.B. unter Linux für einen x86_64-w64-mingw32 Host bauen, oder noch spannender: x86_64-w64-mingw32 Host und x86_64-linux-gnu Target (nenn mich bescheuert, aber hab ich alles schon gemacht ). Besonders in solchen Cross-Szenarios treten in dem Autotools-Projekt Probleme auf, die extrem schwer zu debuggen sind und die sehr obskure Lösungen erfordern (wenn er z.B. bei irgendeiner Operation die Wand läuft, weil er eine gebaute Datei ausführen will, das aber auf dem Build-System gar nicht geht, weil es z.B. eine Windows-.exe ist. Oder dass irgendwelche Teile des Builds lustig irgendwelche Pfade und Libraries vom (Linux-) Build-System verwenden, obwohl das Host-System gar kein Linux ist).

Wenn ich wie bei MingW-W64 eine eigene, und nicht die auf dem System installierte C-Standardbibliothek dabei habe, musste ich den GCC auch bisher immer in mehreren Schritten bauen. Zumindest wenn ich sicherstellen will, dass die libc ebenfalls mit dem neuen Compiler gebaut wird: Erst die Header installieren, damit configure die findet, dann nur den Compiler bauen (ohne von libc abhängige Bibliotheken), mit diesem dann die libc und dann den Rest des GCC-Projekts (u.a. z.B. die libstdc++).

Da spielt wahrscheinlich auch noch meine Anforderung herein, dass die Toolchain "portabel" sein soll, d.h. sie kann in ein beliebiges Verzeichnis kopiert werden und verwendet dann entsprechende Standard-Library+Include-Pfade relativ zur Binary. Auch da musste ich bisher immer ein paar Dateien herumkopieren und verschieben, damit das reibungslos funktioniert. Und genau hier würde ich dann auch das Standard-Module bauen und an eine entsprechende Stelle kopieren.

*john 0

@Finnegan sagte in GCC 15.1.0 und Modules:

Ich meinte damit die Standardverzeichnisse, in denen der Compiler nach den passenden .gcm-Dateien sucht (sowas wie Standard-Library/Include-Verzeichnisse). Das wird hoffentlich nicht nur ./gcm_cache sein

Es findet sich keinerlei *.gcm im Compilerzeichnis unter /opt/gcc-15.1.0, wo ich den Compiler installiert habe. Da finden sich alle Compiler spezifischen Includes und Libraries aber eben keinerlei *.gcm Dateien. D.h. der Compiler übersetzt das Standardmodul nicht bei der Installation, sondern man muss das pro Projekt jedesmal selbst machen. Und ich wenn ich mit strace -f das überwache sehe ich auch kein Standardverzeichnis in dem der Compiler danach suchen würde, so dass man es von Hand übersetzen und dort ablegen könnte, so dass er das finden würde. Stattdessen sucht der GCC nach etlichen *.gcm Versionen von Standard C Header, die er Zwecks Optimierung nutzen will, und in der Standard Installation nicht finden kann. Für C++ Module macht er das noch nicht. Also, ein todo für eine der nächsten GCC Versionen.

Ja, ich dachte mir schon sowas. Das ist auch der gut ausgetretene "Standardpfad". Wenn man von dem abweicht, läuft man häufiger auf diverse Probleme, die ein eigenes Skript drumherum notwendig machen. So z.B. unter Linux für einen x86_64-w64-mingw32 Host bauen, oder noch spannender: x86_64-w64-mingw32 Host und x86_64-linux-gnu Target (nenn mich bescheuert, aber hab ich alles schon gemacht ). Besonders in solchen Cross-Szenarios treten in dem Autotools-Projekt Probleme auf, die extrem schwer zu debuggen sind und die sehr obskure Lösungen erfordern (wenn er z.B. bei irgendeiner Operation die Wand läuft, weil er eine gebaute Datei ausführen will, das aber auf dem Build-System gar nicht geht, weil es z.B. eine Windows-.exe ist. Oder dass irgendwelche Teile des Builds lustig irgendwelche Pfade und Libraries vom (Linux-) Build-System verwenden, obwohl das Host-System gar kein Linux ist).

Meine Erfahrungen mit Crosscompiler selbst bauen sind schon recht alt, die GCC Distribution war damals noch recht überschaubar, und ich kann nur soviel dazu schreiben – mein Beileid.