Hva er MinGW-w64 Verktøykjeden?

MinGW-w64 i seg selv er en pakke som tilbyr deklarasjoner, C kjøretidsbiblioteker og mye mer. Når støtte for det er innebygd i kompilatorer som GCC, muliggjør det bygging av programvare rettet mot Windows, for eksempel programmer og biblioteker. Denne programvaren er ment å brukes på Windows, men kan også brukes på Linux.

[Notat]

Notat

LLVM kan også brukes til verktøykjeden. Denne boken vil bruke GCC i stedet fordi den har enklere instruksjoner, raskere byggetider og sparer diskplass.

Wine-10.13 avhenger av denne funksjonaliteten for å bygge DLL-er (dynamiske lenkebiblioteker), eller tilsvarende dynamiske Linux biblioteker, lagt til med suffikset .so, eller delte objekter.

Mesteparten av Windows-programvaren er dynamisk koblet. Selv om de fleste av dem, når de leveres, inkluderer DLL-er pakket i den installerte mappen, eller hentet fra en ZIP fil, vil ikke alle DLL-er bli pakket. En rekke av avhengighetene vil allerede være installert på en gitt Windows-maskin, for eksempel biblioteker for DirectX/Direct3D eller OpenGL støtte. Siden vi bruker et Unix lignende operativsystem, har vi ikke slike DLL-er installert på systemet, og de ble aldri kompilert i LFS eller tidligere i denne boken. NVIDIA-580.76.05 installerer DLL filer, men er strengt tatt ment for Wine og Proton som en måte å eksponere DLSS på. MinGW-w64 installerer bare statiske biblioteker, som er nyttige når man kompilerer Windows programvare, men er ubrukelige under kjøring. Wine må kompilere de dynamiske bibliotekene for at mesteparten av Windows programvaren skal fungere.

Hvis du er en utvikler og ønsker å sikte deg inn på Windows, bør denne verktøykjeden være ganske nyttig. Du trenger ikke å følge noen av kapitlene etter dette hvis du bare vil ha MinGW-w64 verktøykjeden. Det anbefales å fortsatt installere Wine for tilregnelighetskontroller knyttet til den innebygde programvaren du utvikler, selv om det ikke er en perfekt erstatning for et nøyaktig Windows miljø. Selv om den innebygde programvaren kan fungere fint med Wine, kan den være helt ødelagt på Windows.

Følgende prosess går opp til å bygge delene (Windows deklarasjoner og binutils for å koble og sette sammen Windows programvare) for en statisk kompilering av GCC, noe som betyr at den ikke kan gjøre stort annet med dynamiske biblioteker enn å bygge dem. Dette er spesielt et problem med C++ programvare, siden du trenger libstdc++, som bør være dynamisk, for kobling og utførelse. Dette er også et problem for programvare som bruker Atomic. Mest av alt trenger Windows programvare bygget med verktøykjeden libgcc_s_seh som ikke er levert i den statiske byggingen.

Denne enkle verktøykjeden er imidlertid nok til å bygge opp de gjenværende delene av verktøykjeden. Etter å ha gjort det, kan du gjenoppbygge GCC og ha en komplett verktøykjede klar for målretting mot Windows. Realistisk sett kan du hente en binær distribusjon av verktøykjeden og kompilere alt med færre trinn. Tidligere var det akkurat det denne boken har gjort. GLFS redaktører/bidragsytere har siden den gang bestemt seg for å skrote den ideen. [14] og har valgt å bootstrappe verktøykjeden i stedet.



[14] Se dette issue for begrunnelsen bak oppstart av MinGW-w64 verktøykjeden. Problemet stammer fra det gamle Github depotet som GLFS prosjektet en gang var vert for.