Ristikääntäjä - Cross compiler

Ohjelman suoritus
Yleiset käsitteet
Koodityypit
Kokoamisstrategiat
Merkittäviä käyttöaikoja
Merkittäviä kääntäjiä ja työkaluketjuja

Risti kääntäjä on kääntäjä pystyy luomaan suoritettavan koodin alusta muu kuin se, johon kääntäjä on käynnissä. Esimerkiksi kääntäjä, joka toimii tietokoneella, mutta luo koodin, joka toimii Android -älypuhelimella, on ristikääntäjä.

Ristikääntäjä on välttämätön koodin kääntämiseksi useille alustoille yhdestä kehityspalvelimesta. Suora kääntäminen kohdealustalle saattaa olla mahdotonta, esimerkiksi sulautetuissa järjestelmissä, joissa on rajalliset laskentaresurssit.

Ristikääntäjät eroavat lähdekoodista . Ristikääntäjä on tarkoitettu konekoodin generoimiseen eri alustoilla , kun taas lähde-lähde-kääntäjä kääntää tekstikoodissa ohjelmointikieleltä toiselle. Molemmat ovat ohjelmointityökaluja .

Käyttää

Ristikääntäjän peruskäyttö on erottaa rakennusympäristö kohdeympäristöstä. Tästä on hyötyä useissa tilanteissa:

  • Sulautetut tietokoneet, joissa laitteella on erittäin rajalliset resurssit. Esimerkiksi mikroaaltouunissa on erittäin pieni tietokone, joka lukee näppäimistön ja ovianturin, tuottaa ulostulon digitaalinäyttöön ja kaiuttimeen sekä ohjaa ruoanlaittokoneita. Tämä tietokone ei yleensä ole tarpeeksi tehokas kääntäjän, tiedostojärjestelmän tai kehitysympäristön suorittamiseen.
  • Kääntäminen useille koneille. Yritys voi esimerkiksi haluta tukea useita käyttöjärjestelmän eri versioita tai tukea useita eri käyttöjärjestelmiä. Ristikääntäjää käyttämällä voidaan luoda yksi koontiversioympäristö, joka voidaan kääntää kullekin näistä kohteista.
  • Kääntäminen palvelintilalla . Samanlainen kuin useiden koneiden kääntäminen, monimutkainen kokoonpano, joka sisältää monia kääntämistoimintoja, voidaan suorittaa millä tahansa ilmaisella koneella riippumatta sen taustalla olevasta laitteistosta tai sen käyttöjärjestelmäversiosta.
  • Käynnistys uudelle alustalle. Kun kehitetään ohjelmistoja uudelle alustalle tai tulevan alustan emulaattorille, käytetään ristikääntäjää tarvittavien työkalujen, kuten käyttöjärjestelmän ja alkuperäisen kääntäjän, kokoamiseen.
  • Natiivikoodin kokoaminen emulaattoreille vanhemmille, vanhentuneille alustoille, kuten Commodore 64 tai Apple II, harrastajille, jotka käyttävät ristikääntäjiä, jotka toimivat nykyisellä alustalla (kuten Aztec C: n MS-DOS 6502 ristikääntäjät, jotka toimivat Windows XP: ssä ).

Käyttö virtuaalikoneiden (kuten Javan JVM ) ratkaisee joitakin syitä, joiden rajat kerääjiä kehitettiin. Virtuaalikoneparadigma sallii saman kääntäjälähdön käytön useissa kohdejärjestelmissä, vaikka tämä ei aina ole ihanteellista, koska virtuaalikoneet ovat usein hitaampia ja koottu ohjelma voidaan ajaa vain tietokoneilla, joissa on kyseinen virtuaalikone.

Tyypillisesti laitearkkitehtuuria eroaa (esim ohjelmaa koostettaessa määränpäänä MIPS-arkkitehtuurille koskevasta x86 tietokone), mutta rajat kokoelma on sovellettavissa myös silloin, kun vain käyttöjärjestelmä ympäristö eroaa, koska koostettaessa FreeBSD ohjelmaansa Linux , tai jopa vain järjestelmän kirjastoon , kuten käännettäessä ohjelmia uClibc -ohjelmalla glibc -isäntään.

Kanadan risti

Kanadalainen Risti on tekniikka rakentaa rajat kerääjiä muille koneille. Annettiin kolme konetta A, B ja C, yksi käyttää koneessa (esim käynnissä Windows XP koskevasta IA-32 prosessori) rakentaa rajat kääntäjä, joka toimii koneessa B (esim käynnissä Mac OS X koskevasta x86-64 prosessori) ja luoda ajettavat koneen C (esim käynnissä Android koskevasta ARM -prosessori). Kun käytetään Kanadan ristiä GCC: n kanssa, mukana voi olla neljä kääntäjää

  • Oma natiivi Compiler kone A (1) (esim kääntäjä Microsoft Visual Studio ) on tarkoitus rakentaa gcc natiivi kääntäjä koneen A (2) .
  • Gcc natiivi kääntäjä kone A (2) on tarkoitus rakentaa gcc rajat kääntäjä koneen A kone B (3)
  • Gcc rajat kääntäjä koneen A kone B (3) on tarkoitus rakentaa gcc rajat kääntäjä koneen B kone C (4)

Esimerkki Kanadan rististä, malli

Lopputuloksen ristikääntäjä (4) ei voi toimia rakennuskoneella A; sen sijaan se suorittaisi koneella B kääntääkseen sovelluksen suoritettavaksi koodiksi, joka sitten kopioidaan koneelle C ja suoritetaan koneella C.

Esimerkiksi NetBSD tarjoaa POSIX Unix -skriptin nimeltä, build.shjoka rakentaa ensin oman työkaluketjun isännän kääntäjän kanssa; tätä puolestaan ​​käytetään ristikääntäjän rakentamiseen, jota käytetään koko järjestelmän rakentamiseen.

Termi Kanadan risti syntyi, koska silloin, kun näistä kysymyksistä keskusteltiin, Kanadalla oli kolme kansallista poliittista puoluetta.

Aikaisten ristikääntäjien aikajana

  • 1979 - ALGOL 68C synnytti ZCODEn ; tämä auttoi kääntäjän ja muiden ALGOL 68 -sovellusten siirtämisessä vaihtoehtoisille alustoille. ALGOL 68C -kääntäjän kääntäminen vaati noin 120 kt muistia. Kanssa Z80 sen 64 kt muistia on liian pieni todella kääntää kääntäjä. Joten Z80: n osalta kääntäjä itse oli käännettävä ristikkäisesti suuremmasta CAP -tietokoneesta tai IBM System/370 -yksiköstä.

GCC ja ristikokoelma

GCC , ilmainen ohjelmistokokoelma kääntäjiä, voidaan asettaa ristikääntämiseen. Se tukee monia alustoja ja kieliä.

GCC edellyttää, että koottu kopio binutileista on saatavilla jokaiselle kohdennetulle alustalle. Erityisen tärkeä on GNU Assembler . Siksi binutils on ensin käännettävä oikein kytkimellä, joka --target=some-targetlähetetään konfigurointikomentoon . GCC on myös määritettävä samalla --targetvaihtoehdolla. GCC voidaan sitten ajaa normaalisti edellyttäen, että binutilsin luomat työkalut ovat käytettävissä polussa , mikä voidaan tehdä seuraavalla tavalla (UNIX-tyyppisissä käyttöjärjestelmissä, joissa on bash): 

PATH=/path/to/binutils/bin:${PATH} make

Cross-kokoamiseen GCC edellyttää, että osa kohdekäyttöympäristöksi: n C standardin kirjasto on saatavilla isäntäalustalla . Ohjelmoija voi kääntää koko C -kirjaston, mutta tämä valinta voi olla epäluotettava. Vaihtoehto on käyttää newlibia , joka on pieni C -kirjasto, joka sisältää vain C -lähdekoodin kääntämiseen tarvittavat olennaisimmat komponentit .

GNU Autotools paketit (eli autoconf , automake ja libtool ) käyttää käsitteestä rakennetun lavan , joka on isäntä alustan ja kohdealusta . Rakennetun lavan on, jos kääntäjä on koonnut. Useimmissa tapauksissa koontiversio tulee jättää määrittelemättömäksi (oletusarvo on isäntä). Isäntä alusta on aina kun tuotos esineitä kääntäjä toteutetaan onko tuotos on toinen kääntäjä vai ei. Kohdealustaan käytetään, kun rajat kokoamiseen rajat kerääjiä, se edustaa minkälainen kohdekoodia itse pakkauksen tuottaa; muuten kohdealustan asetuksella ei ole merkitystä. Harkitse esimerkiksi Dreamcastissa toimivan videopelin ristikokoonpanoa . Kone, johon peli kootaan, on koontialusta, kun taas Dreamcast on isäntäalusta . Nimet isäntä ja kohde ovat suhteessa käytettyyn kääntäjään ja siirretty kuten poika ja pojanpoika .

Toinen menetelmä, jota sulautetut Linux -kehittäjät käyttävät yleisesti, sisältää GCC -kääntäjien yhdistämisen erikoistuneisiin hiekkalaatikoihin, kuten Scratchbox , scratchbox2 tai PRoot . Nämä työkalut luovat " chrooted " hiekkalaatikon, johon ohjelmoija voi rakentaa tarvittavat työkalut, libc ja kirjastot ilman ylimääräisiä polkuja. Käytettävissä on myös toimintoja, jotka "pettävät" ajonaikaa niin, että se "uskoo", että se todella toimii suunnitellulla kohde -CPU: lla (kuten ARM -arkkitehtuuri); tämä mahdollistaa määrityskomentosarjojen ja vastaavien suorittamisen ilman virheitä. Scratchbox toimii hitaammin kuin "ei-chroted" -menetelmät, ja useimmat isäntäkoneessa olevat työkalut on siirrettävä Scratchboxiin toimiakseen.

Manx Aztec C ristikääntäjät

Manx Software Systems , Shrewsbury , New Jersey , tuotti 1980 -luvulta lähtien C -kääntäjiä , jotka on suunnattu ammattikehittäjille erilaisille alustoille, mukaan lukien PC ja Mac .

Manxin Aztec C -ohjelmointikieli oli saatavana useille alustoille, kuten MS-DOS , Apple II , DOS 3.3 ja ProDOS , Commodore 64 , Macintosh 68XXX ja Amiga .

1980-luvulta lähtien ja jatkui koko 1990-luvun, kunnes Manx Software Systems katosi, Aztec C: n MS-DOS-versiota tarjottiin sekä natiivitilan kääntäjänä että ristikääntäjänä muille alustoille, joissa on eri prosessorit, kuten Commodore 64 ja Apple II. Aztec C: lle on edelleen olemassa Internet-jakeluja, mukaan lukien niiden MS-DOS-pohjaiset ristikääntäjät. Ne ovat käytössä vielä tänäkin päivänä.

Manxin Aztec C86, natiivitila 8086 MS-DOS-kääntäjä, oli myös ristikääntäjä. Vaikka se ei kääntänyt koodia eri prosessorille, kuten Aztec C65 6502 -kääntäjille Commodore 64: lle ja Apple II: lle, se loi binääriset suoritettavat tiedostot vanhoille käyttöjärjestelmille 16-bittiselle 8086-prosessoriperheelle.

Kun IBM PC esiteltiin ensimmäisen kerran, se oli saatavana useilla käyttöjärjestelmillä, joista kaksi CP/M-86 ja PC DOS . Aztec C86: ssa oli linkkikirjastoja koodin luomiseksi molemmille IBM PC -käyttöjärjestelmille. Koko 1980-luvun Aztec C86: n myöhemmät versiot (3.xx, 4.xx ja 5.xx) lisäsivät tukea MS-DOS "ohimeneville" versioille 1 ja 2, jotka olivat vähemmän kestäviä kuin "perus" MS-DOS-versio 3 ja myöhemmin Aztec C86 tavoitti sen kuolemaansa asti.

Lopuksi Aztec C86 tarjosi C-kielen kehittäjille mahdollisuuden tuottaa ROM-yhteensopivaa "HEX" -koodia, joka voidaan sitten siirtää ROM-polttimen avulla suoraan 8086-pohjaiseen prosessoriin. Paravirtualisointi voi olla nykyään yleisempi, mutta käytäntö luoda matalan tason ROM-koodia oli yleisempää asukasta kohden vuosina, jolloin laiteohjaimen kehittämistä tekivät usein sovellusohjelmoijat yksittäisille sovelluksille ja uudet laitteet olivat kotiteollisuutta . Ei ollut harvinaista, että sovellusohjelmoijat liittyivät suoraan laitteistoon ilman valmistajan tukea. Tämä käytäntö oli samanlainen kuin sulautettujen järjestelmien kehittäminen tänään.

Aztec-C: n kaksi pääkehittäjää olivat Thomas Fenwick ja James Goodnow II. Fenwick tuli myöhemmin tunnetuksi Microsoft Windows CE -ydin tai NK ("Uusi ydin"), kuten sitä silloin kutsuttiin, kirjoittajana.

Microsoft C ristikääntäjät

Varhainen historia - 1980 -luku

Microsoft C: llä (MSC) on lyhyempi historia kuin muilla 1980 -luvulla. Ensimmäiset Microsoft C -kääntäjät valmisti sama yritys, joka teki Lattice C: n, ja Microsoft muutti ne uudelleen omikseen, kunnes MSC 4 julkaistiin, mikä oli ensimmäinen Microsoftin itse tuottama versio.

Vuonna 1987 monet kehittäjät alkoivat siirtyä Microsoft C: een, ja monet muut seurasivat Microsoft Windowsin kehityksen aikana nykyiseen tilaansa. Clipperin ja myöhemmin Clarionin kaltaisia ​​tuotteita, jotka tarjosivat helppoa tietokannasovellusten kehittämistä ristikielen tekniikoiden avulla, jolloin osa ohjelmistaan ​​voidaan koota Microsoft C: llä.

Borland C (Kalifornian yritys) oli ostettavissa vuosia ennen kuin Microsoft julkaisi ensimmäisen C -tuotteensa.

Kauan ennen Borlandia BSD Unix (Berkeleyn yliopisto) oli saanut C: n C -kielen kirjoittajilta : Kernighanilta ja Ritchieltä, jotka kirjoittivat sen yhdessä työskennellessään AT&T: ssä (labs). K&R: n alkuperäinen tarve ei ollut pelkästään tyylikäs 2. tason jäsennetty syntaksi ASM: n 1. tason jäsennetyn syntaksin korvaamiseksi: se on suunniteltu siten, että minimaalinen määrä ASM -tiedostoja kirjoitetaan jokaisen alustan tueksi (C: n alkuperäinen muotoilu oli kyky ristikääntää C: tä käyttäen vähiten tukikoodia alusta kohti, jota he tarvitsivat.) Myös eilen C liittyi suoraan ASM -koodiin missä tahansa, joka ei ole alustasta riippuvainen. Nykyinen C (enemmän kuin c ++) ei ole enää C-yhteensopiva, ja sen taustalla oleva asm-koodi voi olla erittäin erilainen kuin tietyllä alustalla kirjoitettu (Linuxissa: se joskus korvaa ja kiertää kirjastokutsut jakelijavalinnoilla). Nykyinen C on kolmannen tai neljännen tason kieli, jota käytetään vanhaan tapaan kuin toisen tason kieli.

1987

C -ohjelmat oli jo pitkään liitetty kokoonpanokielellä kirjoitettuihin moduuleihin . Useimmat C -kääntäjät (jopa nykyiset kääntäjät) tarjoavat kokoonpanokielisen passin (jota voidaan säätää tehokkuuden parantamiseksi ja yhdistää sitten muuhun ohjelmaan kokoamisen jälkeen).

Aztec-C: n kaltaiset kääntäjät muuttivat kaiken kokoonpanokieleksi erillisenä passina ja koottivat sitten koodin erilliseen passiin, ja ne tunnettiin erittäin tehokkaasta ja pienestä koodistaan, mutta vuoteen 1987 mennessä Microsoft C: hen rakennettu optimoija oli erittäin hyvä ja vain Ohjelman "operatiivisesti kriittisiä" osia harkittiin yleensä uudelleen kirjoittamista varten. Itse asiassa C-kieliohjelmointi oli siirtynyt "alimman tason" kieleksi, ja ohjelmoinnista tuli monialainen kasvuala ja hankkeet laajenivat, ja ohjelmoijat kirjoittivat käyttöliittymiä ja tietokantarajapintoja korkeamman tason kielillä. syntyi kieltenväliseen kehitykseen, joka jatkuu tähän päivään asti.

Vuoteen 1987 mennessä, kun MSC 5.1 julkaistiin, Microsoft tarjosi monikielistä kehitysympäristöä MS-DOS: lle. 16-bittinen binäärikoodikoodi, joka on kirjoitettu kokoonpanokielellä ( MASM ) ja Microsoftin muilla kielillä, mukaan lukien QuickBASIC , Pascal ja Fortran, voitaisiin yhdistää yhteen ohjelmaan prosessissa, jota he kutsuivat "Mixed Language Programming" ja nyt "InterLanguage Calling". Jos BASICia käytettiin tässä yhdistelmässä, pääohjelman piti olla BASICissa, jotta se tukisi sisäistä ajonaikaista järjestelmää, joka kokosi roskien keräämiseen tarvittavan BASICin, ja sen muita hallittuja toimintoja, jotka simuloi BASIC- tulkkia, kuten QBasic MS-DOS: ssa.

Erityisesti C -koodin kutsumiskäytäntö oli välittää parametrit "päinvastaisessa järjestyksessä" pinossa ja palauttaa arvot pinoon prosessorirekisterin sijaan . Muiden ohjelmointisääntöjen avulla kaikki kielet toimivat yhdessä, mutta tämä sääntö säilyi monikielisessä kehityksessä, joka jatkui koko Windows 16- ja 32-bittisten versioiden aikana sekä ohjelmien kehittämisessä OS/2: lle , ja se jatkuu edelleen päivä. Se tunnetaan Pascalin kutsukäytännönä .

Toinen tyyppi rajat kokoelma Microsoftin C käytettiin tänä aikana oli vähittäiskaupan sovelluksissa, joissa tarvitaan kämmentietokoneita kuten Symbol Technologies PDT3100 (tapana viedä varaston ), joka tarjosi linkkikirjasto kohdennettu klo 8088 pohjainen viivakoodi lukija . Sovellus rakennettiin isäntätietokoneeseen ja siirrettiin sitten kämmenlaitteeseen ( sarjakaapelin kautta ), jossa se ajettiin, samalla tavalla kuin Symbolin ostaneet Motorola -yritykset tekevät nykyään samoille markkinoille Windows Mobilea käyttämällä .

1990 -luvun alku

Koko 1990-luvun alusta alkaen MSC 6: sta (heidän ensimmäinen ANSI C -yhteensopiva kääntäjä) Microsoft kohdisti C-kääntäjänsä uudelleen kehittyville Windows-markkinoille sekä OS/2-järjestelmään ja GUI- ohjelmien kehittämiseen . MSC 6: n kautta MS-DOS-puolella pysyi sekakielinen yhteensopivuus, mutta Microsoft Windows 3.0: n ja 3.1: n sovellusliittymä on kirjoitettu MSC 6: een. MSC 6: ta laajennettiin myös tukemaan 32-bittisiä kokoonpanoja ja tukea uusille Windows for Workgroups ja Windows NT, joka muodostaisi perustan Windows XP: lle . Ohjelmointikäytäntö, jota kutsuttiin thunkiksi, otettiin käyttöön 16- ja 32-bittisten ohjelmien välillä, jotka käyttivät ajonaikaista sidontaa ( dynaaminen linkitys ) sen sijaan, että staattinen sidonta olisi suosittu monoliittisissa 16-bittisissä MS-DOS-sovelluksissa. Jotkut natiivikoodikehittäjät suosivat edelleen staattista sitomista, mutta se ei yleensä tarjoa sitä koodin uudelleenkäyttöastetta, jota uusimmat parhaat käytännöt, kuten Capability Maturity Model (CMM), edellyttävät.

MS-DOS-tuki saatiin edelleen julkaisemalla Microsoftin ensimmäinen C ++ -kääntäjä, MSC 7, joka oli taaksepäin yhteensopiva C-ohjelmointikielen ja MS-DOS: n kanssa ja tuki sekä 16- että 32-bittistä koodin luomista.

MSC otti haltuunsa siitä, mihin Aztec C86 jäi. C-kääntäjien markkinaosuus oli kääntynyt ristikääntäjien puoleen, jotka hyödynsivät uusimpia ja suurimpia Windows-ominaisuuksia, tarjosivat C- ja C ++ -paketteja yhdessä paketissa ja tukivat edelleen jo kymmenen vuotta vanhoja MS-DOS-järjestelmiä sekä Aztec C: n kaltaiset kääntäjät eivät enää pystyneet kilpailemaan ja joko kääntyivät kapeille markkinoille, kuten sulautetut järjestelmät, tai katosivat.

MS-DOS- ja 16-bittisen koodin luontituki jatkui, kunnes MSC 8.00c, joka oli mukana Microsoft C ++: ssa ja Microsoft Application Studio 1.5: ssä, Microsoft Visual Studion edeltäjänä .

1990 -luvun loppu

MSC 12 julkaistiin Microsoft Visual Studio 6: n kanssa, eikä se enää tukenut 16-bittisiä MS-DOS-binaaritiedostoja, vaan tuki 32-bittisille konsolisovelluksille, mutta tuki Windows 95- ja Windows 98 -koodin luomiselle sekä Windows NT: lle . Linkkikirjastoja oli saatavana muille Microsoft Windowsia käyttäville prosessoreille; käytäntö, jota Microsoft jatkaa tähän päivään asti.

MSC 13 julkaistiin Visual Studio 2003 : n kanssa ja MSC 14 julkaistiin Visual Studio 2005: n kanssa , jotka molemmat tuottavat edelleen koodia vanhemmille järjestelmille, kuten Windows 95, mutta jotka tuottavat koodia useille kohdealustoille, mukaan lukien mobiilimarkkinat ja ARM -arkkitehtuuri .

.NET ja sen jälkeen

Vuonna 2001 Microsoft kehitti Common Language Runtimen (CLR), joka muodosti Visual Studio IDE: n .NET Framework -kääntäjän ytimen . Tämä sovellusliittymässä olevan käyttöjärjestelmän kerros mahdollistaa Windows -käyttöjärjestelmää käyttäville alustoille koottujen kehityskielten sekoittamisen.

.NET Framework -suoritusaika ja CLR tarjoavat kartoituskerroksen prosessorin ja kohdetietokoneen ydinrutiineille. Visual Studion komentorivin C-kääntäjä kääntää natiivikoodin useille prosessoreille, ja sitä voidaan käyttää ydinrutiinien luomiseen itse.

Microsoft .NET-sovellukset kohdealustoille, kuten Windows Mobile , ARM-arkkitehtuurin ristikääntämiselle Windows-koneille, joissa on useita suorittimia, ja Microsoft tarjoaa myös emulaattoreita ja etäkäyttöympäristöjä, jotka vaativat hyvin vähän kokoonpanoa, toisin kuin ristikääntäjät menneinä päivinä muut alustat.

Suorituksenaikaiset kirjastot, kuten Mono , tarjoavat yhteensopivuuden ristikokotettujen .NET-ohjelmien kanssa muihin käyttöjärjestelmiin, kuten Linuxiin .

Kirjastot, kuten Qt ja sen edeltäjät, mukaan lukien XVT, tarjoavat lähdekooditason kehityskyvyn muiden alustojen kanssa ja käyttävät silti Microsoft C: tä Windows -versioiden rakentamiseen. Muista kääntäjistä, kuten MinGW: stä, on tullut myös suosittuja tällä alalla, koska ne ovat suoraan yhteensopivia Unixien kanssa, jotka sisältävät ohjelmistokehityksen ei-Windows-puolen, jolloin nämä kehittäjät voivat kohdistaa kaikki alustat tutun rakennusympäristön avulla.

Ilmainen Pascal

Free Pascal kehitettiin alusta alkaen ristikääntäjäksi. Suoritettava kääntäjä (ppcXXX, jossa XXX on kohdearkkitehtuuri) pystyy tuottamaan suoritettavia tiedostoja (tai vain objektitiedostoja, jos sisäistä linkkiä ei ole, tai jopa vain kokoonpanotiedostoja, jos sisäistä kokoonpanoa ei ole) kaikille saman arkkitehtuurin käyttöjärjestelmille. Esimerkiksi ppc386 pystyy tuottamaan suoritettavia tiedostoja i386-linux-, i386-win32-, i386-go32v2 (DOS) ja kaikille muille käyttöjärjestelmille (katso). Toiseen arkkitehtuuriin kääntämistä varten on kuitenkin ensin rakennettava kääntäjän ristiarkkitehtuuriversio. Tuloksena olevan kääntäjän suoritettavan tiedoston nimessä olisi ylimääräinen ross ennen kohdearkkitehtuuria. eli jos kääntäjä on rakennettu kohdentamaan x64, suoritettava tiedosto olisi ppcrossx64.

Voit kääntää valitulle arkkitehtuuri -OS: lle kääntäjäkytkintä (kääntäjän ohjaimelle fpc) -P ja -T. Tämä tehdään myös silloin, kun kääntäjä ristikääntää itseään, mutta se asetetaan make-vaihtoehdolla CPU_TARGET ja OS_TARGET. Kohdealustan GNU -kokoonpanija ja linkittäjä vaaditaan, jos Free Pascalilla ei vielä ole sisäistä versiota kohdealustan työkaluista.

Kalahtaa

Clang on alun perin ristikääntäjä, ja rakennusvaiheessa voit valita, mihin arkkitehtuureihin haluat Clangin kohdistavan.

Katso myös

Viitteet

Ulkoiset linkit