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.
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.