EngelsFransSpaans

Ad


OnWorks-favicon

aarch64-linux-gnu-gcj - Online in de cloud

Voer aarch64-linux-gnu-gcj uit in OnWorks gratis hostingprovider via Ubuntu Online, Fedora Online, Windows online emulator of MAC OS online emulator

Dit is de opdracht aarch64-linux-gnu-gcj die kan worden uitgevoerd in de gratis hostingprovider van OnWorks met behulp van een van onze meerdere gratis online werkstations zoals Ubuntu Online, Fedora Online, Windows online emulator of MAC OS online emulator

PROGRAMMA:

NAAM


gcj - Ahead-of-time compiler voor de Java-taal

KORTE INHOUD


gcj [-Idir...] [-d dir
[--KLASSENPAD=pad] [--klaspad=pad]
[-foptie...] [--codering=naam]
[--hoofd=naam van de klasse] [-Dnaam[=waarde]...]
[-C] [--bron naam van de bron] [-d directory]
[-Wwaarschuwen
bron bestand...

PRODUCTBESCHRIJVING


As gcj is gewoon weer een front-end voor gcc, ondersteunt het veel van dezelfde opties als gcc.
Deze handleiding documenteert alleen de opties die specifiek zijn voor: gcj.

OPTIES


Invoer en uitgang bestanden
A gcj commando is als een gcc commando, in die zin dat het bestaat uit een aantal opties en bestand
namen. De volgende soorten invoerbestandsnamen worden ondersteund:

filet.Java
Java-bronbestanden.

filet.klasse
Java bytecode-bestanden.

filet.zip
filet.jar
Een archief met een of meer ".class"-bestanden, die allemaal zijn gecompileerd. De
archief kan worden gecomprimeerd. Bestanden in een archief die niet eindigen op .klasse zijn
behandeld als bronbestanden; ze worden gecompileerd in het resulterende objectbestand als kern:
URL's.

@filet
Een bestand met een door spaties gescheiden lijst van invoerbestandsnamen. (Momenteel zijn deze
moeten allemaal ".java" bronbestanden zijn, maar dat kan veranderen.) Elk genoemd bestand wordt gecompileerd,
net alsof het op de opdrachtregel had gestaan.

bibliotheek.a
bibliotheek.zo
-llibnaam
Bibliotheken om te gebruiken bij het koppelen. Zie de gcc manual.

U kunt meer dan één invoerbestand specificeren op de gcj opdrachtregel, in welk geval ze zullen
allemaal worden samengesteld. Als u een "-o BESTANDSNAAM" optie, worden alle invoerbestanden
samen gecompileerd, waardoor een enkel uitvoerbestand wordt geproduceerd, genaamd BESTANDSNAAM. Dit is zelfs toegestaan
bij gebruik van "-S" of "-c", maar niet bij gebruik van "-C" of "--resource". (Dit is een extensie
voorbij de wat vlakte gcc staat toe.) (Als er meer dan één invoerbestand is opgegeven, moeten alle
momenteel ".java"-bestanden zijn, hoewel we hopen dit op te lossen.)

Invoer Opties
gcj heeft opties om te bepalen waar het kijkt om bestanden te vinden die het nodig heeft. Bijvoorbeeld, gcj macht
moet een klasse laden waarnaar wordt verwezen door het bestand dat is gevraagd om te compileren. Leuk vinden
andere compilers voor de Java-taal, gcj heeft een idee van een klasse pad. Er zijn
verschillende opties en omgevingsvariabelen die kunnen worden gebruikt om het klassenpad te manipuleren.
. gcj zoekt naar een bepaalde klasse, het zoekt het klassepad op zoek naar overeenkomsten .klasse
or .Java bestand. gcj wordt geleverd met een ingebouwd klassenpad dat verwijst naar de geïnstalleerde
libgcj.jar, een bestand dat alle standaardklassen bevat.

In de onderstaande tekst kan een directory- of padcomponent verwijzen naar een daadwerkelijke directory
op het bestandssysteem, of naar een .zip or .jar bestand, dat gcj zal zoeken alsof het een
directory.

-Idir
Alle mappen gespecificeerd door "-I" worden op volgorde gehouden en toegevoegd aan het klassenpad
opgebouwd uit alle andere opties. Tenzij compatibiliteit met tools zoals "javac"
belangrijk is, raden we aan altijd "-I" te gebruiken in plaats van de andere opties voor:
het klassenpad manipuleren.

--klassenpad=pad
Dit stelt het klassenpad in op pad, een door dubbele punten gescheiden lijst met paden (op Windows-gebaseerd
systemen, een door puntkomma's gescheiden lijst met paden). Dit heeft geen voorrang op de ingebouwde
("boot") zoekpad.

--KLASSENPAD=pad
Verouderd synoniem voor "--classpath".

--bootklassepad=pad
Waar vind je de standaard ingebouwde klassen, zoals "java.lang.String".

--extmappen=pad
Voor elke map in de pad, plaats de inhoud van die map aan het einde van de
klasse pad.

KLASPAD
Dit is een omgevingsvariabele die een lijst met paden bevat.

Het uiteindelijke klassenpad is als volgt opgebouwd:

* Eerst komen alle mappen gespecificeerd via "-I".

* Als --klaspad is opgegeven, wordt de waarde toegevoegd. Anders, als de "CLASSPATH"
omgevingsvariabele is opgegeven, wordt de waarde ervan toegevoegd. Anders, de huidige
directory (".") wordt toegevoegd.

* Als "--bootclasspath" is opgegeven, voegt u de waarde ervan toe. Voeg anders de ingebouwde
systeemmap, libgcj.jar.

* Ten slotte, als "--extdirs" is opgegeven, voeg dan de inhoud van de opgegeven toe
mappen aan het einde van het klassenpad. Voeg anders de inhoud van de
ingebouwde extdirs op "$(prefix)/share/java/ext".

Het klassenbestand gebouwd door gcj voor de klasse "java.lang.Object" (en geplaatst in "libgcj.jar")
bevat een speciaal kenmerk met een lengte van nul "gnu.gcj.gcj-compiled". De compiler zoekt naar
dit kenmerk bij het laden van "java.lang.Object" en zal een fout rapporteren als het niet wordt gevonden,
tenzij het compileert naar bytecode (de optie "-fforce-classes-archive-check" kan worden gebruikt om
negeer dit gedrag in dit specifieke geval.)

-fforce-classes-archief-check
Dit dwingt de compiler om altijd te controleren op het speciale lengtekenmerk nul
"gnu.gcj.gcj-compiled" in "java.lang.Object" en geef een foutmelding als deze niet wordt gevonden.

-fbron=VERSIE
Deze optie wordt gebruikt om de bronversie te kiezen die wordt geaccepteerd door gcj. De standaardwaarde is 1.5.

coderingen
De programmeertaal Java gebruikt overal Unicode. In een poging om goed te integreren
met andere plaatsen, gcj toestaat .Java bestanden die met bijna elke codering moeten worden geschreven. gcj
weet hoe deze coderingen in de interne codering moeten worden omgezet tijdens het compileren.

U kunt de "--encoding=NAAM" optie om een ​​codering op te geven (van een bepaald teken)
set) om te gebruiken voor bronbestanden. Als dit niet is opgegeven, komt de standaardcodering van:
uw huidige landinstelling. Als uw hostsysteem onvoldoende lokale ondersteuning heeft, dan: gcj
gaat ervan uit dat de standaardcodering de is UTF-8 codering van Unicode.

Om "--encoding" te implementeren, gcj gebruikt eenvoudig de "iconv"-conversieroutine van het hostplatform.
Dit betekent dat in de praktijk gcj wordt beperkt door de mogelijkheden van het hostplatform.

De namen die zijn toegestaan ​​voor het argument "--encoding" variëren van platform tot platform (omdat ze
zijn nergens gestandaardiseerd). Echter, gcj implementeert de codering genaamd UTF-8
intern, dus als u ervoor kiest om dit voor uw bronbestanden te gebruiken, kunt u er zeker van zijn dat het
werkt op elke host.

waarschuwingen
gcj implementeert verschillende waarschuwingen. Net als bij andere generieke gcc waarschuwingen, als een optie van de
formulier "-Wfoo" schakelt een waarschuwing in, vervolgens zal "-Wno-foo" deze uitschakelen. Hier hebben we voor gekozen:
documenteer de vorm van de waarschuwing die een effect zal hebben -- de standaard is de
tegenovergestelde van wat wordt vermeld.

-Wredundante-modifiers
Met deze vlag gcj zal waarschuwen voor overbodige modifiers. Het zal bijvoorbeeld waarschuwen
als een interfacemethode "openbaar" wordt verklaard.

-Wexterne-puntkomma
Dit veroorzaakt gcj om te waarschuwen voor lege verklaringen. Lege verklaringen zijn geweest
verouderd.

-Wno-verouderd
Deze optie zorgt ervoor dat gcj om niet te waarschuwen wanneer een bronbestand nieuwer is dan het overeenkomende
klasse bestand. Standaard gcj zal hiervoor waarschuwen.

-Wno-verouderd
Waarschuwen als er wordt verwezen naar een verouderde klasse, methode of veld.

-Wongebruikt
Dit is hetzelfde als gcc's "-Wunused".

-Muur
Dit is hetzelfde als "-Wredundant-modifiers -Wextraneous-puntkomma -Wunused".

Koppelen
Om van een Java-toepassing een uitvoerbaar programma te maken, moet u deze koppelen aan de benodigde
bibliotheken, net als voor C of C++. De linker zoekt standaard naar een globale functie met de naam
"hoofd". Aangezien Java geen globale functies heeft, en een verzameling Java-klassen mogelijk
meer dan één klasse hebben met een "hoofd" -methode, moet u de linker laten weten welke van
die "hoofd"-methoden die het moet gebruiken bij het starten van de toepassing. Dat kan je doen in
een van deze manieren:

* Specificeer de klasse die de gewenste "main"-methode bevat wanneer u de applicatie koppelt,
met behulp van de "--main" vlag, hieronder beschreven.

* Koppel het/de Java-pakket(ten) aan een gedeelde bibliotheek (dll) in plaats van een uitvoerbaar bestand. Vervolgens
roep de applicatie op met behulp van het "gij"-programma en zorg ervoor dat "gij" de . kan vinden
bibliotheken die het nodig heeft.

* Koppel de Java-pakketten met de vlag "-lgij", die linkt in de "main" routine
van het "gij"-commando. Hiermee kunt u de klasse selecteren waarvan u de "hoofd" -methode hebt
wilt uitvoeren wanneer u de toepassing uitvoert. U kunt ook andere "gij"-vlaggen gebruiken, zoals
"-D" vlaggen om eigenschappen in te stellen. Met behulp van de "-lgij" bibliotheek (in plaats van de "gij"
programma van het vorige mechanisme) heeft enkele voordelen: het is compatibel met static
koppelen, en vereist geen configuratie of installatie van bibliotheken.

Deze "gij"-opties hebben betrekking op het koppelen van een uitvoerbaar bestand:

--hoofd=NAAM VAN DE KLASSE
Deze optie wordt gebruikt bij het koppelen om de naam van de klasse te specificeren waarvan de "hoofd"-methode
moet worden aangeroepen wanneer het resulterende uitvoerbare bestand wordt uitgevoerd.

-Dnaam[=waarde]
Deze optie kan alleen worden gebruikt met "--main". Het definieert een systeemeigenschap met de naam naam
met waarde waarde. Indien waarde niet is opgegeven, wordt standaard de lege tekenreeks gebruikt.
Deze systeemeigenschappen worden geïnitialiseerd bij het opstarten van het programma en kunnen worden opgehaald
tijdens runtime met behulp van de "java.lang.System.getProperty"-methode.

-lgij
Maak een toepassing waarvan de opdrachtregelverwerking die is van de opdracht "gij".

Deze optie is een alternatief voor het gebruik van "--main"; je kunt niet beide gebruiken.

-statische-libgcj
Deze optie zorgt ervoor dat het koppelen wordt gedaan tegen een statische versie van de libgcj runtime
bibliotheek. Deze optie is alleen beschikbaar als de bijbehorende linkerondersteuning bestaat.

Voorzichtigheid: Statische koppeling van libgcj kan ertoe leiden dat essentiële delen van libgcj worden weggelaten.
Sommige delen van libgcj gebruiken reflectie om klassen tijdens runtime te laden. Aangezien de linker doet
deze verwijzingen niet zien tijdens de koppelingstijd, kan het de verwezen naar klassen weglaten. De
resultaat is meestal (maar niet altijd) een "ClassNotFoundException" die tijdens runtime wordt gegenereerd.
Voorzichtigheid is geboden bij het gebruik van deze optie. Voor meer details zie:
<http://gcc.gnu.org/wiki/Statically%20linken%20libgcj>

Code Generatie
In aanvulling op de vele gcc opties die het genereren van codes regelen, gcj heeft verschillende opties
specifiek voor zichzelf.

-C Deze optie wordt gebruikt om te vertellen gcj bytecode genereren (.klasse bestanden) in plaats van object
code.

--bron naam van de bron
Deze optie wordt gebruikt om te vertellen gcj om de inhoud van een bepaald bestand te compileren naar objectcode
dus het kan tijdens runtime worden geopend met de kernprotocol-handler als: kern:/middel-
naam. Merk op dat naam van de bron is de naam van de resource zoals gevonden tijdens runtime; voor
het kan bijvoorbeeld worden gebruikt in een aanroep naar "ResourceBundle.getBundle". Het eigenlijke bestand
naam die op deze manier moet worden gecompileerd, moet afzonderlijk worden opgegeven.

-fdoel=VERSIE
Dit kan worden gebruikt met -C om de versie van de bytecode te kiezen die wordt uitgezonden door gcj. De
standaard is 1.5. Als er geen bytecode wordt gegenereerd, heeft deze optie geen effect.

-d directory
Bij gebruik met "-C" zorgt dit ervoor dat alle gegenereerde .klasse bestanden die in de moeten worden geplaatst
geschikte submap van directory. Standaard worden ze in submappen geplaatst
van de huidige werkdirectory.

-fno-grenzen-controle
Standaard gcj genereert code die de grenzen van alle array-indexering controleert
activiteiten. Met deze optie worden deze controles weggelaten, wat de prestaties kan verbeteren
voor code die veel gebruik maakt van arrays. Houd er rekening mee dat dit kan leiden tot onvoorspelbare
gedrag als de code in kwestie daadwerkelijk de beperkingen van de arraygrenzen schendt. Het
is het veilig om deze optie te gebruiken als je zeker weet dat je code nooit een
"ArrayIndexOutOfBoundsException".

-fno-winkel-check
Genereer geen matrixopslagcontroles. Bij het opslaan van objecten in arrays, een runtime-controle
wordt normaal gegenereerd om ervoor te zorgen dat het object toewijzingscompatibel is met:
het componenttype van de array (die mogelijk niet bekend is tijdens het compileren). Hiermee
optie, worden deze controles weggelaten. Dit kan de prestaties verbeteren voor code die wordt opgeslagen
objecten vaak in arrays. Het is veilig om deze optie te gebruiken als u zeker weet dat uw
code zal nooit een "ArrayStoreException" genereren.

-fjni
met gcj er zijn twee opties voor het schrijven van native methoden: CNI en JNI. Standaard
gcj gaat ervan uit dat u CNI gebruikt. Als je een klasse compileert met native methoden, en
deze methoden worden geïmplementeerd met behulp van JNI, dan moet u "-fjni" gebruiken. Deze optie
oorzaken gcj om stubs te genereren die de onderliggende JNI-methoden zullen aanroepen.

-fno-beweren
Herken het trefwoord 'beweren' niet. Dit is voor compatibiliteit met oudere versies
van de taalspecificatie.

-fno-optimaliseren-statische-klasse-initialisatie
Wanneer het optimalisatieniveau groter of gelijk is aan "-O2", gcj zal proberen de te optimaliseren
manier waarop de runtime wordt aangeroepen om statische klassen te initialiseren bij het eerste gebruik
(deze optimalisatie wordt niet uitgevoerd als "-C" is opgegeven.) Bij het compileren naar native
code, "-fno-optimize-static-class-initialisatie" zal deze optimalisatie uitschakelen,
ongeacht het gebruikte optimalisatieniveau.

--disable-beweringen[=klasse-of-pakket]
Neem geen code op voor het controleren van beweringen in de gecompileerde code. Indien
"=klasse-of-pakket" ontbreekt, schakelt het genereren van beweringscodes uit voor alle klassen,
tenzij overschreven door een meer specifieke "--enable-assertions" vlag. Indien klasse-of-pakket
is een klassenaam, schakelt alleen het genereren van beweringcontroles binnen de genoemde klasse uit of
zijn innerlijke klassen. Indien klasse-of-pakket is een pakketnaam, schakelt genereren uit
beweringcontroles binnen het genoemde pakket of een subpakket.

Standaard zijn beweringen ingeschakeld bij het genereren van klassenbestanden of bij het niet optimaliseren,
en uitgeschakeld bij het genereren van geoptimaliseerde binaire bestanden.

--enable-beweringen[=klasse-of-pakket]
Genereert code om beweringen te controleren. De optie heeft misschien een verkeerde naam, omdat je nog steeds nodig hebt
om beweringcontrole tijdens runtime in te schakelen, en we ondersteunen geen eenvoudige manier om dit te doen
Dat. Dus deze vlag is nog niet erg nuttig, behalve om gedeeltelijk te negeren
"--disable-beweringen".

-findirect-verzending
gcj heeft een speciale binaire compatibiliteit ABI, die wordt ingeschakeld door de
"-findirect-dispatch" optie. In deze modus wordt de code gegenereerd door gcj eert de
binaire compatibiliteitsgaranties in de Java-taalspecificatie, en de resulterende
objectbestanden hoeven niet direct te worden gekoppeld aan hun afhankelijkheden. In plaats daarvan,
alle afhankelijkheden worden tijdens runtime opgezocht. Dit maakt een vrije vermenging van geïnterpreteerde en
gecompileerde code.

Merk op dat op dit moment "-findirect-dispatch" alleen kan worden gebruikt bij het compileren .klasse
bestanden. Het zal niet werken bij het compileren vanaf de bron. CNI werkt ook nog niet mee
de binaire compatibiliteit ABI. Deze beperkingen zullen in de toekomst worden opgeheven
vrij.

Als u echter CNI-code compileert met de standaard ABI, kunt u deze vanuit code oproepen
gebouwd met de binaire compatibiliteit ABI.

-fbootstrap-klassen
Deze optie kan worden gebruikt om "libgcj" te vertellen dat de gecompileerde klassen moeten worden geladen door
de bootstrap-lader, niet de systeemklasse-lader. Standaard, als je een klasse compileert
en koppel het aan een uitvoerbaar bestand, het zal worden behandeld alsof het is geladen met behulp van de
systeem klasse lader. Dit is handig, want het betekent dat dingen als:
"Class.forName()" zal zoeken KLASPAD om de gewenste klasse te vinden.

-freduced-reflectie
Deze optie zorgt ervoor dat de code gegenereerd door gcj om een ​​verminderd deel van de klas te bevatten
metagegevens die worden gebruikt om runtime-reflectie te ondersteunen. De kosten van deze besparing zijn het verlies van
de mogelijkheid om bepaalde reflectiemogelijkheden van de standaard Java-runtime te gebruiken
omgeving. Wanneer alle metagegevens zijn ingesteld, behalve die welke nodig zijn om correct te verkrijgen
runtime-semantiek wordt geëlimineerd.

Voor code die geen reflectie gebruikt (dwz serialisatie, RMI, CORBA of oproepmethoden)
in het "java.lang.reflect" pakket), zal "-freduced-reflection" resulteren in proper
bewerking met een besparing in uitvoerbare codegrootte.

JNI ("-fjni") en de binaire compatibiliteit ABI ("-findirect-dispatch") werken niet
zonder volledige reflectie meta-data. Hierdoor is het een fout om te gebruiken
deze opties met "-freduced-reflection".

Voorzichtigheid: Als er geen reflectie-metagegevens zijn, kan code die een "SecurityManager" gebruikt,
niet goed werken. Ook het aanroepen van "Class.forName()" kan mislukken als de aanroepmethode heeft
geen reflectie meta-data.

Configureertijd Opties
sommige gcj opties voor het genereren van codes hebben invloed op de resulterende ABI, en kunnen dus alleen
zinvol gegeven wanneer "libgcj", het runtime-pakket, is geconfigureerd. "libgcj" zet de
passende opties uit deze groep in a spec bestand dat wordt gelezen door gcj. Deze opties
worden hier voor de volledigheid vermeld; als u "libgcj" gebruikt, wilt u niet aanraken
deze opties.

-zekering-boehm-gc
Dit maakt het gebruik van de Boehm GC bitmap-markeringscode mogelijk. Dit veroorzaakt in het bijzonder
gcj om een ​​objectmarkeringsdescriptor in elke vtable te plaatsen.

-fhash-synchronisatie
Standaard worden synchronisatiegegevens (de gegevens die worden gebruikt voor "synchroniseren", "wachten", en
"notify") wordt aangeduid met een woord in elk object. Met deze optie gcj gaat ervan uit dat
deze informatie wordt opgeslagen in een hashtabel en niet in het object zelf.

-zekering-verdeel-subroutine
Op sommige systemen wordt een bibliotheekroutine aangeroepen om deling op gehele getallen uit te voeren. Dit is
vereist om de afhandeling van uitzonderingen correct te krijgen bij delen door nul.

-fcheck-referenties
Op sommige systemen is het nodig om inline controles in te voegen bij het openen van een object
via een verwijzing. Op andere systemen heb je dit niet nodig omdat null pointer toegang heeft
worden automatisch opgevangen door de processor.

-fuse-atomaire-ingebouwde
Op sommige systemen kan GCC code genereren voor ingebouwde atomaire bewerkingen. Gebruik dit
optie om gcj te dwingen deze ingebouwde elementen te gebruiken bij het compileren van Java-code. Waar
mogelijkheid aanwezig is, zou het automatisch moeten worden gedetecteerd, dus je hebt het meestal niet nodig
om deze optie te gebruiken.

Gebruik aarch64-linux-gnu-gcj online met behulp van onworks.net-services


Gratis servers en werkstations

Windows- en Linux-apps downloaden

Linux-commando's

Ad