Przydatne opcje kompilatora

From MorphOS Library

Revision as of 12:54, 6 April 2011 by Krashan (talk | contribs) (Translation in progress.)

Grzegorz Kraszewski


Ten artykuł w innych językach: angielski


Kompilator GCC ma setki opcji. Znaczna część z nich nie jest istotna z punktu widzenia typowego użycia pod MorphOS-em. Część z nich nie jest istotna z punktu widzenia architektury PowerPC. W artykule opisany jest zestaw najważniejszych opcji potrzebnych w kompilowaniu programów dla MorphOS-a. Szczegółowy opis wszystkich parametrów znajduje się w instrukcji obsługi GCC.

Kompilacja i linkowanie

Dla każdego projektu składającego się z więcej niż jednego pliku z kodem, proces budowania gotowego programu jest podzielony na dwa etapy: kompilację i linkowanie. Kompilacja zamienia każdy plik z kodem źródłowym na plik zawierający odpowiadający mu kod wykonywalny procesora (ang. object file). Linkowanie łączy pliki wygenerowane przez kompilator w gotowy plik wykonywalny programu. Dla prostych projektów mieszczących się w jednym pliku źródłowym, te dwa etapy połączone są w jeden proces.

Oba etapy budowania programu mają swoje parametry. Część opcji jest brana pod uwage tylko przy kompilacji, część tylko przy linkowaniu, niektóre są ważne dla obu. Na szczęście nazwy parametrów dla obu etapów nigdy się nie pokrywają, dlatego bezpiecznym rozwiązaniem jest podanie wszystkich żądanych opcji w obu etapach. Nadmiarowe parametry zostaną po prostu zignorowane.


Kolejność parametrów

Generalnie rzecz biorąc, kolejność parametrów podawanych w GCC nie jest istotna. Są jednak od tej ogólnej zasady ważne wyjątki. Najważniejszym z nich jest podawanie linkerowi nazw bibliotek statycznych, z jakimi ma zostać zlinkowany program. Przypuśćmy, że linkujemy z dwiema bibliotekami libfoo.a i libbar.a. Wymaga to podania linkerowi dwóch parametrów: −lfoo −lbar. Jeżeli jednak bibkioteka libbar używa funkcji z libfoo, parametr −lfoo musi być podany po parametrze −lbar. W przeciwnym wypadku linker nie będzie w stanie rozwinąć wszystkich symboli z libbar.


Opcje ostrzeżeń kompilatora

Opcje te kontrolują przed jakimi potencjalnie niebezpiecznymi konstrukcjami programistycznymi kompilator będzie nas ostrzegał. Niektórzy programiści narzekają na kompilator (zwłaszcza na wersję GCC 4), że "czepia się nieistotnych szczegółów". Mimo to warto włączyć większość ostrzeżeń, może to zaoszczędzić wielu godzin spędzonych na wyszukiwaniu błędów w programie...

−Wall, turns on warnings for typical potentially dangerous language constructs. Example ones are using a value of assignment as a logical condition, or using arithmetic on void* pointers. While syntactically legal, such constructs may be a result of mistyping, and even when used intentionally, may produce errors that can be very hard to debug. This option is a must for any reasonable programmer.

−Wextra, turns on even more warnings (this option is −W in GCC 2.95.3). There is no serious reason to not use this option together with −Wall.


Note: GCC4 has an irritating feature. String literals are assumed to be arrays of fixed char type. Almost all the MorphOS API functions expect strings to be of type STRPTR which is a typedef of unsigned char*. Passing literals to these functions produces tons of warnings. The clean way to avoid it, is to explicitly cast every literal passed to the MorphOS API as STRPTR. An alternative is to suppress these warnings with −Wno-pointer-sign. The disadvantage of this second solution is that it also suppresses pointer signedness warnings for all other integer types, not only for char.


Linker options

−noixemul, instructs the linker to use the static libnix library for standard C/C++ functions and startup code. Without this parameter, the shared library ixemul.library is used. Read more.

−s, instructs the linker to strip debug information and symbol tables. This information is not needed in a release executable. Stripping them lowers the executable size significantly.


Optimization options

−On, where n ranges from 0 to 3. The parameter is a global control of execution speed optimizer. Higher numbers make the optimizer more aggressive. −O2 seems to be the best for everyday use. −O3 turns on many optimizations which can significantly increase the executable size. Good programmers optimize their algorithms in the first place, compiler optimizations can't fix design errors...

−Os, turns on executable size optimization, at the cost of execution speed. Not very useful for typical applications.