Useful Compiler Options - Revision history

Krashan: Note about the third solution for GCC4 string literals idiosyncrasy.

2011-04-06T12:45:27Z

Note about the third solution for GCC4 string literals idiosyncrasy.

Krashan: Added crosslink to Polish version.

2011-04-05T07:12:19Z

Added crosslink to Polish version.

Krashan at 09:54, 25 October 2010

2010-10-25T09:54:15Z

Krashan: AusPPC fixes.

2010-10-25T08:54:45Z

AusPPC fixes.

Krashan: No fixed styles.

2010-10-24T09:38:09Z

No fixed styles.

Krashan: Fixed library linking example logic.

2010-10-23T15:05:03Z

Fixed library linking example logic.

Krashan: style again

2010-10-23T15:02:56Z

style again

Krashan: style

2010-10-23T15:02:27Z

style

Krashan: spacing

2010-10-23T14:41:25Z

spacing

Krashan: /* Warning options */

2010-10-23T14:39:59Z

‎Warning options

← Older revision		Revision as of 12:45, 6 April 2011
Line 27:		Line 27:


−	<small>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''.</small>	+	<small>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''. Another solution, good for a new code is overriding the definition of ''STRPTR'' and derived types. It can be done by placing the following code ''before'' the header file ''<exec/types.h>'' is included
		+
		+	typedef char* STRPTR;
		+	typedef const char* CONST_STRPTR;
		+	#define STRPTR_TYPEDEF
		+
		+	When using this, one must be '''absolutely sure''' that no arithmetic (assuming the signedness) is performed on strings pointed by ''STRPTR'' pointers. If such arithmetic must be used, types should be casted to either ''signed char'' or ''unsigned char'' explicitly. Using this solution on old, uninspected code is dangerous.</small>

← Older revision		Revision as of 07:12, 5 April 2011
Line 1:		Line 1:
	''Grzegorz Kraszewski''		''Grzegorz Kraszewski''
		+	----
		+	<small>This article in other languages: [[Przydatne opcje kompilatora\|Polish]]</small>

← Older revision		Revision as of 09:54, 25 October 2010
Line 13:		Line 13:
	==Options order==		==Options order==

−	The order of passing options to GCC is not important in general. There are some critical exceptions however. The most common one is order of passing static libraries to the linker. Let's assume linking with two static libraries ''libfoo.a'' and ''libbar.a''. This requires passing ''-lfoo -lbar'' parameters to the linker. However, in the case where ''libbar'' uses functions from ''libfoo'', the ''-lfoo'' option must be passed '''after''' the ''-lbar'' option. The linker will be left with unresolved symbols in ''libbar'' otherwise.	+	The order of passing options to GCC is not important in general. There are some critical exceptions however. The most common one is order of passing static libraries to the linker. Let's assume linking with two static libraries ''libfoo.a'' and ''libbar.a''. This requires passing ''−lfoo −lbar'' parameters to the linker. However, in the case where ''libbar'' uses functions from ''libfoo'', the ''−lfoo'' option must be passed '''after''' the ''−lbar'' option. The linker will be left with unresolved symbols in ''libbar'' otherwise.

@@ Line 2: / Line 2: @@
-GCC compiler has hundreds of options. Some of them are irrelevant for typical usage, some of them are irrelevant for PowerPC architecture. This article presents a set of common options used when compiling MorphOS programs. For detailed descriptions of all options see [http://gcc.gnu.org/onlinedocs/ GCC manual].
+The GCC compiler has hundreds of options. Some of them are irrelevant for typical usage, some of them are irrelevant for PowerPC architecture. This article presents a set of common options used when compiling MorphOS programs. For detailed descriptions of all options see the [http://gcc.gnu.org/onlinedocs/ GCC manual].
 ==Compiling and linking==
-For every project consisting of more than one source files, process of building the executable program is divided into two stages: compiling and linking. Compilation turns every source code file into an object file. Linking merges all object files (and static libraries) into the final executable. For simple single file projects, these two stages merge into one.
+For every project consisting of more than one source file, the process of building the executable program is divided into two stages: compiling and linking. Compilation turns every source code file into an object file. Linking merges all object files (and static libraries) into the final executable. For simple single file projects, these two stages merge into one.
 Both the stages have different options. Some options are relevant only for compiling, some only for linking, and some are important for both. Fortunately option names never overlap. Then the safe solution is to pass '''all''' the desired options for both stages. Irrelevant ones will be simply ignored.
@@ Line 13: / Line 13: @@
 ==Options order==
-The order of passing options to GCC is not important in general. There are some critical exceptions however. The most common one is order of passing static libraries to the linker. Let's assume linking with two static libraries ''libfoo.a'' and ''libbar.a''. It means passing ''-lfoo -lbar'' parameters to the linker. However, in the case when ''libbar'' uses functions from ''libfoo'', ''-lfoo'' option must be passed '''after''' ''-lbar''. The linker will be left with unresolved symbols in ''libbar'' otherwise.
+The order of passing options to GCC is not important in general. There are some critical exceptions however. The most common one is order of passing static libraries to the linker. Let's assume linking with two static libraries ''libfoo.a'' and ''libbar.a''. This requires passing ''-lfoo -lbar'' parameters to the linker. However, in the case where ''libbar'' uses functions from ''libfoo'', the ''-lfoo'' option must be passed '''after''' the ''-lbar'' option. The linker will be left with unresolved symbols in ''libbar'' otherwise.
 ==Warning options==
-These options control warnings issued by compiler on some potentially dangerous language constructs. While some programmers complain on compiler being too picky, it is recommended to turn most of these options on. It can save hours of time wasted on debugging...
+These options control warnings issued by the compiler on some potentially dangerous language constructs. While some programmers complain about the compiler being too picky, it is recommended to turn most of these options on. It can save hours of time wasted on debugging...
-'''&minus;Wall''', turns on warnings for typical potentially dangerous language constructs. Example ones are using value of assignment as logical condition, or arithmetic on ''void*'' pointers. While syntactically legal, such constructs may be a result of mistyping, and even when used intentionally, may produce errors very hard to debug. This option is a must for any reasonable programmer.
+'''&minus;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.
 '''&minus;Wextra''', turns on even more warnings (this option is '''&minus;W''' in GCC 2.95.3). There is no serious reason to not use this option together with '''&minus;Wall'''.
-<small>Note: GCC4 has some irritating feature. String literals are assumed to be arrays of fixed ''char'' type. Almost all 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 MorphOS API to ''STRPTR''. Some alternative is to suppress these warnings with '''&minus;Wno-pointer-sign'''. The disadvantage of this second solution is suppressing pointer signedness warnings for all integer types, not only for ''char''.</small>
+<small>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 '''&minus;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''.</small>
 ==Linker options==
-'''&minus;noixemul''', instructs linker to use static ''libnix'' library for standard C/C++ functions and startup code. Without this parameter, shared library ''ixemul.library'' is used. [[Installation_of_Software_Development_Kit_and_its_basic_usage#Standard_C_and_C++_Libraries|Read more]].
+'''&minus;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. [[Installation_of_Software_Development_Kit_and_its_basic_usage#Standard_C_and_C++_Libraries|Read more]].
-'''&minus;s''', instructs linker to strip debug information and symbol tables. These informations are not needed in a release executable. Stripping them lowers the executable size significantly.
+'''&minus;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==
-'''&minus;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. '''&minus;O2''' seems to be the best for everyday use. '''&minus;O3''' turns on many optimizations which can significantly increase the executable size. Good programmer optimizes his algorithms in the first place, compiler optimizations can't fix design errors...
+'''&minus;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. '''&minus;O2''' seems to be the best for everyday use. '''&minus;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...
-'''&minus;Os''', turns on executable size optimization, at a cost of execution speed. Not very useful for typical applications.
+'''&minus;Os''', turns on executable size optimization, at the cost of execution speed. Not very useful for typical applications.

← Older revision		Revision as of 09:38, 24 October 2010
Line 24:		Line 24:
	'''−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'''.		'''−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'''.

−	<~~p style="font-size: 11px;"~~>Note: GCC4 has some irritating feature. String literals are assumed to be arrays of fixed ''char'' type. Almost all 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 MorphOS API to ''STRPTR''. Some alternative is to suppress these warnings with '''−Wno-pointer-sign'''. The disadvantage of this second solution is suppressing pointer signedness warnings for all integer types, not only for ''char''.</p>	+
		+	<small>Note: GCC4 has some irritating feature. String literals are assumed to be arrays of fixed ''char'' type. Almost all 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 MorphOS API to ''STRPTR''. Some alternative is to suppress these warnings with '''−Wno-pointer-sign'''. The disadvantage of this second solution is suppressing pointer signedness warnings for all integer types, not only for ''char''.</small>

← Older revision		Revision as of 15:05, 23 October 2010
Line 13:		Line 13:
	==Options order==		==Options order==

−	The order of passing options to GCC is not important in general. There are some critical exceptions however. The most common one is order of passing static libraries to the linker. Let's assume linking with two static libraries ''libfoo.a'' and ''libbar.a''. It means passing ''-lfoo -lbar'' parameters to the linker. However, in the case when ''~~libfoo~~'' uses functions from ''~~libbar~~'', ''-~~lbar~~'' option must be passed '''after''' ''-~~lfoo~~''. The linker will be left with unresolved symbols in ''~~libfoo~~'' otherwise.	+	The order of passing options to GCC is not important in general. There are some critical exceptions however. The most common one is order of passing static libraries to the linker. Let's assume linking with two static libraries ''libfoo.a'' and ''libbar.a''. It means passing ''-lfoo -lbar'' parameters to the linker. However, in the case when ''libbar'' uses functions from ''libfoo'', ''-lfoo'' option must be passed '''after''' ''-lbar''. The linker will be left with unresolved symbols in ''libbar'' otherwise.

← Older revision		Revision as of 15:02, 23 October 2010
Line 2:		Line 2:


−	GCC compiler has hundreds of options. Some of them are irrelevant for typical usage, some of them are irrelevant for PowerPC architecture. This article presents a set of common ~~option set~~ used when compiling MorphOS programs. For detailed descriptions of all options see [http://gcc.gnu.org/onlinedocs/ GCC manual].	+	GCC compiler has hundreds of options. Some of them are irrelevant for typical usage, some of them are irrelevant for PowerPC architecture. This article presents a set of common options used when compiling MorphOS programs. For detailed descriptions of all options see [http://gcc.gnu.org/onlinedocs/ GCC manual].

	==Compiling and linking==		==Compiling and linking==

@@ Line 22: / Line 22: @@
 '''&minus;Wextra''', turns on even more warnings (this option is '''&minus;W''' in GCC 2.95.3). There is no serious reason to not use this option together with '''&minus;Wall'''.
-<p style="font-size: 11px;">Note: GCC4 has some irritating feature. String literals are assumed to be arrays of fixed ''char'' type. Almost all MorphOS API functions expects 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 MorphOS API to ''STRPTR''. Some alternative is to suppress these warnings with '''&minus;Wno-pointer-sign'''. The disadvantage of this second solution is suppressing pointer signedness warnings for all integer types, not only for ''char''.</p>
+<p style="font-size: 11px;">Note: GCC4 has some irritating feature. String literals are assumed to be arrays of fixed ''char'' type. Almost all 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 MorphOS API to ''STRPTR''. Some alternative is to suppress these warnings with '''&minus;Wno-pointer-sign'''. The disadvantage of this second solution is suppressing pointer signedness warnings for all integer types, not only for ''char''.</p>
 ==Linker options==