Paketbaurichtlinien für MinGW-Cross-Compiler

Das Ziel des Fedora MinGW-Projekts ist es, Fedora-Nutzern, die ihre Programme für Windows kompilieren möchten, eine optimale Entwicklungsumgebung zu bieten und so die Notwendigkeit der Windows-Nutzung zu minimieren. Bisher mussten Entwickler alle benötigten Bibliotheken und Werkzeuge einzeln portieren und kompilieren – ein enormer Aufwand, der mehrfach unabhängig voneinander durchgeführt wurde. Wir möchten diese Doppelarbeit für Anwendungsentwickler vermeiden, indem wir eine Reihe von Bibliotheken und Entwicklungswerkzeugen bereitstellen, die bereits für die MinGW-Cross-Compiler-Umgebung portiert wurden. Dadurch müssen Entwickler den Anwendungsstack nicht selbst neu kompilieren, sondern können sich ausschließlich auf die notwendigen Änderungen an ihrer eigenen Anwendung konzentrieren.

Die Zielplattformen Win32 und Win64 werden durch die MSVCRT-Laufzeitumgebung unterstützt. Die Zielplattform Win64 wird durch die UCRT-Laufzeitumgebung ebenfalls unterstützt, jedoch nur für die Basis-Toolchain. Builds für UCRT sind derzeit für Pakete oberhalb der Toolchain nicht aktiviert.

Es gibt zwei zulässige Wege, um MinGW-Builds von Software in Fedora bereitzustellen:

Der traditionelle Ansatz vollständig getrennter Quellpakete wurde ursprünglich aufgrund von Bedenken gewählt, dass Instabilitäten in der MinGW-Werkzeugkette oder in Windows-Builds zeitnahe Aktualisierungen des nativen Pakets verhindern könnten. Die Erfahrungen mit Fedora haben seitdem gezeigt, dass dies im Allgemeinen kein Problem darstellt, das die meisten Pakete betrifft, insbesondere wenn die Windows-Unterstützung ein explizit getestetes Ergebnis des Upstream-Projekts ist.

Die Methode der separaten Paketierung ist mit einem deutlich höheren Aufwand verbunden:

Durch den integrierten Paketierungsansatz entsteht für den jeweiligen Paketbetreuer ein geringer Mehraufwand, um die Funktionsfähigkeit der MinGW-Builds sicherzustellen, sowie eine geringe zusätzliche Anzahl an MinGW-spezifischen Fehlerberichten. Dieser Aufwand ist jedoch im Vergleich zur Pflege separater Pakete in der Regel vernachlässigbar.

Vor diesem Hintergrund lautet die Empfehlung der MinGW SIG wie folgt:

Wenn noch kein entsprechendes natives Paket existiert, muss es stets den Standard-Paketreviewprozess von Fedora durchlaufen. Die geplante MinGW-Unterstützung MUSS dem integrierten Paketierungsansatz folgen, um – sofern technisch möglich – sowohl MinGW- als auch native Builds bereitzustellen. Wie bereits erwähnt, gibt es in seltenen Fällen kein entsprechendes natives Paket, sodass ein separater Paketierungsansatz erforderlich ist.

Wenn in Fedora bereits ein entsprechendes natives Paket vorhanden ist, wird bevorzugt, die MinGW-Unterstützung zum nativen Quellpaket hinzuzufügen.

Bei einfachen Änderungen am Quellpaket SOLLTE der Mitwirkende Folgendes tun:

Der bisherige Betreuer des nativen Pakets erhält dadurch einen klaren Überblick über die Auswirkungen der MinGW-Ergänzungen auf sein Paket und kann so die Machbarkeit des integrierten Paketierungsansatzes beurteilen.

Wenn Zweifel an der Durchführbarkeit des integrierten Paketansatzes bestehen, KANN ein Fehlerbericht für das Paket erstellt werden, bevor mit der Diskussion der beiden Paketierungsoptionen mit dem Betreuer des nativen Pakets begonnen wird.

Lehnt der ursprüngliche Paketbetreuer den Vorschlag ab, MinGW-Unterstützung in das bestehende Paket aufzunehmen, muss der reguläre Fedora-Prozess für neue Pakete befolgt werden, um MinGW-Unterstützung gemäß dem Ansatz der separaten Paketierung einzuführen.

Generell sollten cross-kompilierte MinGW-Versionen von Paketen, die bereits nativ in Fedora verfügbar sind, so genau wie möglich dem nativen Fedora-Paket entsprechen. Das bedeutet, sie sollten dieselbe Versionsnummer haben, alle Patches des nativen Fedora-Pakets enthalten und mit denselben Konfigurationsoptionen erstellt werden.

Um dieses Ziel zu erreichen, sollte die MinGW-Unterstützung vorzugsweise den integrierten Paketierungsansatz verwenden.

Für MinGW-Pakete, die auf Fedora cross-kompiliert wurden, gelten die Fedora-Richtlinien, sofern in diesem Dokument nichts anderes angegeben ist. Diese Pakete durchlaufen denselben Reviewprozess, dieselben Git-Administrationsprozesse usw. wie andere Fedora-Pakete.

MinGW-Pakete benötigen eine spezielle Benennung, um die jeweilige CPU-Architektur anzugeben, für die die Binärdateien erstellt wurden. Während eines Build-Vorgangs sollte niemals ein Paket mit dem Präfix mingw- ausgegeben werden. Das Präfix mingw- ist ausschließlich für RPM-Spec-Dateien und den Source-RPM-Dateinamen vorgesehen. Die CPU-architekturspezifischen Pakete werden durch Abschnitte mit %files -n mingw32-foo, %files -n mingw64-foo oder %files -n ucrt64-foo erstellt.

Die Basispakete stellen ein Root-Dateisystem, Basisbibliotheken, Binärprogramme (wie „strip“, „ld“ usw.), den Compiler (gcc) und die Win32/Win64-API bereit. Pakete benötigen möglicherweise eine oder mehrere dieser Abhängigkeiten. Insbesondere sollten fast alle Pakete die Abhängigkeiten mingw32-filesystem, mingw64-filesystem, mingw32-gcc und mingw64-gcc in ihre Baukonfiguration aufnehmen.

Das Ziel des MinGW-Frameworks ist es, Paketbetreuern eine einfache Möglichkeit zu bieten, ihre Pakete für mehrere Zielplattformen mithilfe einer einzigen .spec-Datei zu erstellen. Um Entwickler dabei zu unterstützen, wurden mehrere RPM-Makros entwickelt, die Teil des Pakets mingw-filesystem sind. Diese RPM-Makros werden später in diesen Richtlinien erläutert.

Standardmäßig wird MinGW sowohl für Win32- als auch für Win64-Zielsysteme mit der MSVCRT-Laufzeitumgebung gebaut. Der Bau des Win64-Zielsystems mit der UCRT64-Laufzeitumgebung ist standardmäßig noch nicht aktiviert.

Wenn ein Paket nur für eine Teilmenge dieser Ziele erstellt werden kann, kann dies durch Festlegen einer oder mehrerer der folgenden Optionen angegeben werden:

Jedes MinGW-Paket, das für ein bestimmtes Zielsystem cross-kompiliert wird und Binärdateien erstellt, sollte diese Binärdateien in einem separaten Teilpaket ablegen. Wenn also ein Paket mingw-foo oder foo Binärdateien für Win32 und Win64 mit der MSVCRT-Laufzeitumgebung erstellt, sollten aus dem Source-RPM-Paket zwei Teilpakete mit den Namen mingw32-foo und mingw64-foo entstehen. Wenn ein Paket für die UCRT-Laufzeitumgebung erstellt wird, enthält es zusätzlich ein Teilpaket ucrt64-foo.

Dies bedeutet, dass eine Spec-Datei für alle Ziele die Abschnitte %package und %files enthalten muss.

Bei Verwendung des separaten Paketierungsansatzes müssen Pakete, die Übersetzungen enthalten, %mingw_find_lang anstelle von %find_lang verwenden.

Bei Verwendung des integrierten Paketierungsansatzes müssen Pakete, die Übersetzungen enthalten, %find_lang` gefolgt von `%mingw_find_lang+ verwenden.

Dies führt dazu, dass alle Übersetzungsdateilisten in zielspezifische Dateilisten aufgeteilt werden. Eine Spec-Datei enthält beispielsweise Folgendes:

Dann wird für jedes MinGW-Ziel eine Datei mit den Namen mingw32-foo.lang, mingw64-foo.lang und ucrt64-foo.lang erstellt. Diese Dateilisten können im Abschnitt %files für die Ziele angegeben werden:

Die Integration in das Haupt-Root-Dateisystemlayout erfolgt wie folgt:

Der Großteil des Paketinhalts befindet sich unter dem jeweiligen MinGW-Wurzelverzeichnis, einem der folgenden: /usr/i686-w64-mingw32, /usr/x86_64-w64-mingw32 und /usr/x86_64-w64-mingw32ucrt:

Die MinGW-Cross-Compiler und Binutils sind Fedora-Binärdateien und werden daher gemäß den FHS- und Fedora-Richtlinien in %{_bindir} (d.h. /usr/bin) abgelegt.

Die MinGW-Cross-Compiler und Binutils, die i686-Binärdateien für Windows mit der MSVCRT-Laufzeitumgebung generieren, heißen:

Die gleichen Binärdateien sind in %{_prefix}/i686-w64-mingw32/bin ohne Präfix im Namen vorhanden, d.h.

Dasselbe gilt auch für das x86_64-Zielsystem mit den Laufzeitumgebungen MSVCRT und UCRT. Das Zielsystem mit MSVCRT verwendet das Präfix „x86_64-w64-mingw32“ anstelle von „i686-w64-mingw32“, während UCRT das Präfix „x86_64-w64-mingw32ucrt“ verwendet.

Das Wurzeldateisystem enthält Windows-Programme, DLLs und alle anderen Windows-spezifischen Dateien. Es ist notwendig, da wir Windows-Bibliotheken speichern müssen, um weitere, von ihnen abhängige Bibliotheken einzubinden, und da MinGW einen Speicherort im Wurzelverzeichnis des Dateisystems benötigt.

Der Speicherort für das Win32-Ziel mit MSVCRT-Laufzeitumgebung wird durch das Makro bereitgestellt:

Das Win64-Ziel mit MSVCRT-Laufzeitumgebung wird durch das Makro bereitgestellt:

Das Win64-Ziel mit UCRT-Laufzeitumgebung wird durch das Makro bereitgestellt:

Das Paket mingw-filesystem stellt eine Reihe praktischer Makros für die Cross-Kompilierung der Sysroot-Verzeichnisse und der Werkzeugkette bereit. Die Verwendung dieser Makros ist in allen MinGW-Cross-Kompilierungspaketen, die in Fedora eingebunden werden sollen, obligatorisch.

Um Binärdateien für mehrere Zielplattformen zu erstellen, müssen Befehle wie ./configure und make mehrfach aufgerufen werden (einmal für jede Zielplattform). Würde man dies alles in eine Spec-Datei schreiben, entstünde doppelter Code. Um dies zu vermeiden, wurden mehrere RPM-Makros eingeführt, die die Kompilierung vereinfachen. Diese Makros sind %mingw_configure, %mingw_cmake, %mingw_cmake_kde4, %mingw_qmake_qt4, %mingw_qmake_qt5 und %mingw_make.

Diese Makros verwenden die Kompilierung außerhalb des Quellcodes, um Binärdateien für alle Zielplattformen zu erstellen. Fast alle Pakete unterstützen die Kompilierung außerhalb des Quellcodes oder benötigen nur geringfügige Anpassungen. Die einzigen bisher bekannten Ausnahmen sind zlib und openssl. Pakete, die die Kompilierung außerhalb des Quellcodes nicht unterstützen, erfordern möglicherweise einen anderen Ansatz, z. B. die vollständige Ausführung aller Schritte in der %install-Phase. Sollten Sie auf ein Paket stoßen, das einen anderen Ansatz erfordert, kontaktieren Sie uns bitte über die Fedora MinGW-Mailingliste.

Manche Pakete müssen für jedes Zielsystem mehrfach kompiliert werden. Beispiele hierfür sind Pakete, die einmal für eine statische und einmal für eine dynamische Version erstellt werden müssen. Solche Pakete können dem verwendeten Bauverzeichnis ein benutzerdefiniertes Suffix hinzufügen. Angenommen, Sie haben beispielsweise Folgendes:

Das kann man etwa so umschreiben:

Die meisten Pakete wurden mit dem Befehl make %{?_smp_mflags} erstellt. Im MinGW-Cross-Compiler-Framework muss für alle konfigurierten Ziele %mingw_make %{?_smp_mflags} verwendet werden. Wie beim Makro %mingw_configure kann auch die Umgebungsvariable MINGW_BUILDDIR_SUFFIX verwendet werden, um ein benutzerdefiniertes Suffix für das Bauverzeichnis anzugeben.

Zur Installation des Pakets wurde in fast allen Fällen der Befehl make install DESTDIR=$RPM_BUILD_ROOT verwendet. Dieser kann zu %mingw_make install DESTDIR=$RPM_BUILD_ROOT umgeschrieben werden, um das Paket für alle konfigurierten Ziele zu installieren. Die Umgebungsvariable MINGW_BUILDDIR_SUFFIX kann hier ebenfalls verwendet werden.

Manche Pakete erfordern zusätzliche Anweisungen, bevor die Dateien paketiert werden können. Dieser Code kann unverändert bleiben. Allerdings müssen Sie diese Anweisungen möglicherweise mehrfach duplizieren (für alle konfigurierten Ziele).

Wenn ein Paket Binärdateien enthält, die von einer DLL eines anderen Pakets abhängen, sollten diese Abhängigkeiten in folgender Form ausgedrückt werden:

Dabei ist foo.dll der Name der DLL. Der Name muss in Kleinbuchstaben umgewandelt werden, da Windows-Binärdateien Abhängigkeiten enthalten, die nicht zwischen Groß- und Kleinschreibung unterscheiden. Verwenden Sie für Win32-Binärdateien die Form 'mingw32(foo.dll)' und für Win64-Binärdateien die Form 'mingw64(foo.dll)'.

Die Generierung korrekter Abhängigkeiten erfolgt automatisch. Paketierer sollten ihre Spec-Dateien mit dieser Zeile beginnen:

Alle Binärpakete sollten von mingw32-filesystem oder mingw64-filesystem abhängen (abhängig von den im Paket enthaltenen Dateien).

Alle Spec-Dateien sollten mindestens eine der folgenden Abhängigkeiten in „BuildRequires“ enthalten (abhängig von den Zielen, für die Sie kompilieren möchten):

und alle anderen BuildRequires, die sie benötigen.

Die meisten MinGW-RPM-Makros sind in allen Fedora-Versionen außer denen, die das Ende des Supports erreicht haben, vorhanden. Falls ein Paket jedoch auf ein neu eingeführtes Makro angewiesen ist, sollte eine versionierte Abhängigkeit von den mingw-XX-filesystem-Paketen verwendet werden.

Alle Pakete sollten Folgendes enthalten:

Es sei denn, sie enthalten native Fedora-Programme. Bei Verwendung des separaten Paketierungsansatzes muss das Tag BuildArch im Header der gemeinsamen Spec-Datei vorhanden sein. Bei Verwendung des integrierten Paketierungsansatzes muss das Tag BuildArch im %package-Header für jedes vorhandene MinGW-Teilpaket vorhanden sein.

Alle Bibliotheken müssen als DLLs erstellt werden.

Aufgrund der Besonderheit von Windows werden DLLs im Verzeichnis %{mingw32_bindir} gespeichert, zusammen mit einer Steuerdatei im Verzeichnis %{mingw32_libdir}. Für eine Bibliothek namens foo sähe das beispielsweise so aus:

Die Datei foo.dll ist die Hauptbibliothek, foo.dll.a ist ein Platzhalter, der mit Anwendungen verlinkt wird, damit diese die Bibliothek zur Laufzeit finden können. Alle diese Dateien müssen sich an den angegebenen Speicherorten befinden, damit die Verlinkung erfolgreich hergestellt werden kann. Die Datei .dll kann eine Versionsnummer enthalten, muss dies aber nicht (z.B. foo-0.dll).

Die MinGW-Pakete ermöglichen es Entwicklern, die Windows-Unterstützung ihrer Anwendungen zu kompilieren und zu testen. Darüber hinaus wird erwartet, dass Entwickler mithilfe der MinGW-Paketinhalte Windows-Installationsprogramme (MSIs) für ihre Anwendungen erstellen.

Daher muss die Auflistung der Fedora MinGW-Paketdateien etwas enthalten, das entweder für die Verwendung beim Erstellen/Testen oder für die Erstellung von Windows-Installationsprogrammen erforderlich ist.

Grundsätzlich ist eine Konvertierung zwischen den Ansätzen der separaten und der integrierten Paketierung in beide Richtungen möglich. Beide Ansätze erzeugen exakt dieselben binären RPM-Dateien für MinGW-Inhalte; sie unterscheiden sich lediglich in der Spec-Datei ihres Source-RPMs.

Übergang vom separaten zum integrierten Paketierungsansatz

Übergang vom integrierten zum separaten Paketierungsansatz

In beiden Fällen sollte der Aktualisierungsprozess für Benutzer, die Fedora-Installationen durchführen und aktualisieren, transparent sein.

Es wird empfohlen, solche Konvertierungen ausschließlich in Rawhide durchzuführen. Sollte in einem stabilen Release-Stream eine Umstellung von integrierter auf separate Paketierung erforderlich sein, muss eine einzelne Bohdi-Aktualisierung sowohl die nativen als auch die MinGW-Paketversionen enthalten.

Bei Verwendung des integrierten Paketierungsansatzes MUSS die Erstellung von MinGW-Sub-RPMs deaktiviert werden können, und die Erstellung MUSS standardmäßig deaktiviert sein, außer für die Fedora-Distribution. Dadurch wird sichergestellt, dass das native Paket weiterhin in abgeleiteten Distributionen wie RHEL erstellt werden kann, in denen die MinGW-Werkzeugketten nicht enthalten sind. Dies wird durch eine Bedingung im oberen Bereich der Spec-Datei erreicht:

Anschließend werden alle MinGW-bezogenen %package / %files`-Definitionen und relevanten `%build+- oder %install-Befehle in eine Bedingungsprüfung einbezogen:

Die separate Paket-Spec-Datei extrahiert im Wesentlichen den gesamten Inhalt innerhalb der %{with mingw}-Bedingungen aus dem vorherigen Beispiel und fügt ihn in eine eigenständige Spec-Datei ein.