Formatting code for compiling
[[HomePage]] > [[ComponentHowTo Components and HowTos]] > [[CompilingIndex Compiling]]
====How to Compile Within Puppy Linux====
Compiling, in the context of computer programming, refers to when the programming code that constitutes a particular piece of software (source code), which is written by a human, is //converted// (using a software program generally known as a //compiler//) into a binary package (binary code) which a microprocessor can read or make use of. This conversion is achieved by using the //make// command. Prior to issuing this command some configure options (arguments) are passed to it by running the //configure// script (if it exists, which it normally does). If there is no //configure// script this usually means that there are no configure options available and one may proceed directly to issuing the //make// command. It may also mean that one may need to generate it oneself using //autogen.sh//.
It is not absolutely necessary for one to perform the compiling process since there exist repositories (e,g. http://www.debian.org/distrib/packages) of binary code packages of which individual packages may be modified for Puppy Linux usage. So why bother? Compiling the source code within Puppy Linux produces software that is //optimized// for Puppy. The resultant binary code of the compiling process then usually needs to be prepared for it to be usable by Puppy; this process being called packaging. Compiling and packaging are different processes and both may be considered an art form to perform. Proficiency and skill at performing both processes is only possible with much practice.
Compiling the Linux kernel is dealt with [[CompilingKernel here]]. How to compile software applications now follows.
To be able to compile one needs to set up Puppy with the correct environment for compiling. Read [[http://puppylinux.com/development/compileapps.htm this]] first; and then read //Appendix 1// below. Then continue with the next paragraph.
Acquire the source code of the desired program either as //tar.gz// (//.tgz//), //tar.bz2// or //tar.xz// (//.txz//) file formats (such a file being known as a tarball). To acquire the source code one needs to download it from the program developer's website. The different file formats simply denote the different types of compression used in creating that file. Sometimes software developers only supply binary code packages and no source code, e.g. JavaRuntimeEnvironment, [[libflashplayer]]; sometimes they provide both, e.g. [[libreoffice]], [[qt]], [[syslinux]].
Using [[Tor]] as an example, acquire the source code by entering into the command-line interface:
%%wget -t 0 --retry-connrefused -c -N -S -T 16 -w 1 --random-wait --no-dns-cache -P /mnt/home/downloads --no-cache --no-cookies http://www.torproject.org/dist/tor-0.2.1.30.tar.gz%%
Enter the directory to which the source file was downloaded, in the above example it is ///mnt/home/downloads//:
%%(language-ref)cd /mnt/home/downloads%%
Unpack (extract) the source file (the source code is extracted to a directory called //tor-0.2.1.30//):
%%(language-ref)tar xfv tor-0.2.1.30.tar.gz%%
Enter this source code directory:
%%(language-ref)cd tor-0.2.1.30%%
Always read the README and INSTALL text files for any specific or special instructions.
If a //configure// script is available (look inside the source directory) features can be enabled or disabled. All the available configure options/arguments are listed by executing the following command (always do this since the options available can change with each new software version):
%%(language-ref)./configure --help%%
Execute the //configure// script with appropriate options/arguments which will generate a valid //Makefile// script file within the source directory (only use //-pipe// if >=512MB R.A.M. is available):
**%%(language-ref)./configure CFLAGS="-mtune=native -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" --prefix=/usr --sysconfdir=/etc --localstatedir=/var --host=i486-pc-linux-gnu%%**
If there are errors, and the script does not run to completion, this means that dependencies are missing and would need to be installed first before running //configure// again. For example, [[Tor]] has the dependencies [[libevent]] and [[openssl]] which means that these programs have to be installed __prior__ to running the //configure// script successfully, i.e. to completion.
Then build (compile):
%%(language-ref)make%%
and check:
%%(language-ref)make check%%
and optionally install the program:
%%(language-ref)make install%% (This is optional because one may first proceed to make a PET or SFS package before using it itself to install the software which is usually a more flexible way)
__The process is now complete__ (but this is not the whole picture). The program has been installed and it may be used if you know where the executable file is located (usually at ///usr/bin//). It may be found using the //which// command, e.g.:
%%which tor%%
The above explanation is a general outline. Not all source code will make use of the same configure arguments (options) as given above; many specific cases are provided in this wiki within the software category, e.g. [[libav]], [[pidgin]], [[transmission]].
For an idea of how complex compiling can become examine this [[http://www.murga-linux.com/puppy/viewtopic.php?p=503232#503232 midori]] case.
Some extra notes:
- use //prefix=/usr// and not //prefix=/usr/local// (for the sake of standardization and recommended by BarryK)
- a lot of //Makefiles// will leave the "add debug symbol" option of GCC enabled (it is "-g"). This means that a lot of "text" information is added to your program to facilitate debugging, making the program file significantly larger. When compiling open the //Makefile// and look for a line that sets the C flags (usually CFLAGS = ...). If //-g// is declared it may be deleted. However, there is no need since the //strip// command will remove all debugging information later.
- if the configure script is not available (rare) then this should mean that the //Makefile// script file already exists. (If it exists advanced users may edit it accordingly). If it exists execute the following: %%(language-ref)make CFLAGS="-mtune=native -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}"%% %%(language-ref)make PREFIX=/usr SYSCONFDIR=/etc LOCALSTATEDIR=/var install%%
- //-tune=native// is used when the program is to be used for microprocessors of the same type that was used to compile it
- //-tune=generic// is used when the program is likely to be used with any microprocessor; that is why software package maintainers often make use of it since their packages are going to be shared with many users
- //-tune=[[http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options cpu-type]]//
- to un-install execute the following command (only possible if the source directory was not deleted and/or if the source code provides the facility to un-install) [**Warning**: this will un-install any pre-existing installations as well, from the same locations]: %%(language-ref)make prefix=/usr uninstall%%
- possible [[http://www.murga-linux.com/puppy/viewtopic.php?p=344270&sid=085ff07518550457453de18e810542c3#344270 LDFLAGS]]
Now try compiling these simple cases: [[x264]], [[libvpx]]; [[xvid]] (more demanding; must read INSTALL file)
Ideally one should proceed to create a PET software package from the compilation process. The PET is a special package that is manually created so that it can be subsequently used by any user to automatically install the pre-compiled software //and// any additional supporting files such as menu entries and optionally other customizations. Most users rely on these PET packages for acquiring additional software to their repository. After compiling, some manual tweaking is often required so as to have successfully running software, and that is one reason why PET packages are created since they will contain those modifications. To become self-proficient at software package creation it could take at least a year of practice.
==={{color text="Compile, install, and create the corresponding PET software package" c="black"}}===
First compile:
%%(language-ref)./configure CFLAGS="-mtune=native -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" --prefix=/usr --sysconfdir=/etc --localstatedir=/var --host=i486-pc-linux-gnu && make%%
N.B. If the package is intended for maximum wide distribution, then use //-mtune=generic// instead of //-mtune=native//.
Then install using either method (a) or method (b):
-(a) Installation to a temporary location
Install to a temporary directory ///dev/shm/program_name// for the specific purpose of creating a PET software package [N.B. this sometimes fails and so when the command is issued all the compiled files are installed into the Linux file system and nothing into ///dev/shm/program_name//. If installation at this time into the Linux file system is undesired, the personal storage save file //may// be deleted and a new one created with ease.]
%%(language-ref)make install DESTDIR=/dev/shm/program_name%%
Then use the //strip// command ([[strip a recent version]]) to reduce the size of executables and shared objects (see also [[Pstrip]]):
%%cd /dev/shm/program_name && strip -p -d --strip-unneeded -R .comment -R .note -R .note.ABI-tag program_name/*%%
- (b) //(for advanced users that are proficient at compiling only)// Either (i) or (ii)
(i) Installation to the //existing Linux file system// and simultaneously using the //new2dir// script which offers an option (//option 3//) to create individual packages for the compiled executable files, development files, and documentation files
%%(language-ref)new2dir make install%%
(ii) Installation to a //temporary location// and simultaneously using the //new2dir// script which offers an option (//option 3//) to create separate packages for the compiled executable files, development files, and documentation files (not always successful)
%%(language-ref)new2dir make install DESTDIR=/dev/shm/program_name%%
Then use the //[[dir2pet]]// script which converts a directory into a PET file, e.g. using tor-0.2.1.30 compiled within Wary:
%%(language-ref)dir2pet tor-0.2.1.30-w-20110318%%
The name given to the directory is arbitrary and user-defined, but should be appropriate and comprehensible since the resultant PET file will have the same name. For example, the above directory has been given a date suffix to denote the date of creation of the software package, and the suffix //w// to denote that it was compiled within Puppy Wary. Normally, for software applications one would create additional files to place inside the parent directory before executing //dir2pet// so that menu entries, and icons for the menu and desktop, are made available: see SoftwarePackageCreation
To un-install a PET software package use the Puppy Package Manager: //Menu > Setup > Puppy Package Manager//
These scripts may be useful for assisting with compiling: [[src2pkg]] and Pcompile (references: [[http://www.murga-linux.com/puppy/viewtopic.php?p=320609 1]], [[http://www.murga-linux.com/puppy/viewtopic.php?p=525706#525706 2]]).
==={{color text="Appendix 1" c="black"}}===
To convert Puppy into a complete compiler environment it is necessary to acquire and install a special SFS file that corresponds with the version of Puppy Linux that will be used for compiling. The file has "devx" in its name.
- [[http://distro.ibiblio.org/quirky/ Wary]]
- [[http://distro.ibiblio.org/quirky/ Quirky]]
- [[http://www.brainwavedesigncentral.net/micko01/stuff/puppy/spup/ Puppy 5.3]]
- [[http://distro.ibiblio.org/puppylinux/puppy-5.2.8/ Puppy 5.2.8]]
- [[http://distro.ibiblio.org/puppylinux/puppy-4.3.1/ Puppy 4.3.1]]
__For live CD/DVD and frugal Puppy installations__
- a personal save file has to exist first; at least 512MB in size and with sufficient free space
- place the devx SFS file at ///mnt/home//
- then use //Menu > System > ""BootManager""//
- then re-boot
__For full Puppy installations__
http://puppylinux.com/development/compileapps.htm
__Puppy 1 versions__
//usr_devx.sfs//
==={{color text="Appendix 2" c="black"}}===
__Test 1__
devx file is installed when the command-line interface displays:
%%(language-ref)
# cc
cc: no input files%%
__Test 2__
Save the following as test.c
If using Geany, set it to C and test compile first
/* Example C program */
int main()
{ int i;
for (i = 0; i < 50000; i""++"")
{
printf ("%d",i);
printf (" Puppy is Great\n");
}
return 0;
}
%%gcc test.c -o test && ./test%%
http://members.cox.net/midian/articles/ansic1.htm
==={{color text="Appendix 3" c="black"}}===
Compiling is the process by which a program written in a human readable format is converted to a computer executable format. Programs can be written in assembly language, which is almost "perfect" in the eyes of a computer, very close to binary code.
lda 02
sta #c000
lda #c001
cmp #c000
bne d000
But this is difficult to understand, in C it might look like this:
a=2;
b=c;
if (a != b){
my_subroutine();
}
This is easier to understand (high level language), a simple comparison of two numbers, and depending on the result (if they are different), a sub-program is executed. As computers do not understand "if" and don't have variables (C) but only a stack (assembler), the code must be translated from C to assembler or even better directly to binary code (assembler itself is not binary, but a very simple form of a "high level language" very close to binary code). This translation is "compiling". If you open the resulting "code" in a hex editor, you will only see binary code, values from 0 to 255 "wildly mixed".
==={{color text="Appendix 4" c="black"}}===
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
http://www.gentoo.org/doc/en/gcc-optimization.xml
-O2 option: smaller binary, faster to load from disk, less RAM usage, better cache usage in systems with moderate processor cache, higher reliability.
-O3 option: slight to moderate speed increase for some applications, higher memory (RAM, cache and disk) usage, longer load times from disk, very occasional problems with compilation; expect less than 1% improvement in *overall* execution speed. It could possibly make faster code but the applications that benefit from it are very few, usually image and video decoders and such. However the side effects, like larger binary size, affects everything. Larger binaries use more memory, load slower, cause more disc I/O, etc. So compiling a system with -O3 will have the effect that a few applications run slightly faster at the expense of the rest of the system running slightly slower and becoming less responsive. Linux caches regularly used programs and files in RAM (that's the "cache" part when you run free -m on the command line), so the program may only need loading from the hard disk once (depending on the program and computer usage). Therefore this is less of a problem on systems with large amounts of RAM. A large CPU cache also helps as it is better suited to larger binaries, so you are more likely to see some sort of speed up. So if you have a high end system, you will suffer less from the problems associated with -O3.
----
==Categories==
CategoryDevelopment
CategoryCompiling
====How to Compile Within Puppy Linux====
Compiling, in the context of computer programming, refers to when the programming code that constitutes a particular piece of software (source code), which is written by a human, is //converted// (using a software program generally known as a //compiler//) into a binary package (binary code) which a microprocessor can read or make use of. This conversion is achieved by using the //make// command. Prior to issuing this command some configure options (arguments) are passed to it by running the //configure// script (if it exists, which it normally does). If there is no //configure// script this usually means that there are no configure options available and one may proceed directly to issuing the //make// command. It may also mean that one may need to generate it oneself using //autogen.sh//.
It is not absolutely necessary for one to perform the compiling process since there exist repositories (e,g. http://www.debian.org/distrib/packages) of binary code packages of which individual packages may be modified for Puppy Linux usage. So why bother? Compiling the source code within Puppy Linux produces software that is //optimized// for Puppy. The resultant binary code of the compiling process then usually needs to be prepared for it to be usable by Puppy; this process being called packaging. Compiling and packaging are different processes and both may be considered an art form to perform. Proficiency and skill at performing both processes is only possible with much practice.
Compiling the Linux kernel is dealt with [[CompilingKernel here]]. How to compile software applications now follows.
To be able to compile one needs to set up Puppy with the correct environment for compiling. Read [[http://puppylinux.com/development/compileapps.htm this]] first; and then read //Appendix 1// below. Then continue with the next paragraph.
Acquire the source code of the desired program either as //tar.gz// (//.tgz//), //tar.bz2// or //tar.xz// (//.txz//) file formats (such a file being known as a tarball). To acquire the source code one needs to download it from the program developer's website. The different file formats simply denote the different types of compression used in creating that file. Sometimes software developers only supply binary code packages and no source code, e.g. JavaRuntimeEnvironment, [[libflashplayer]]; sometimes they provide both, e.g. [[libreoffice]], [[qt]], [[syslinux]].
Using [[Tor]] as an example, acquire the source code by entering into the command-line interface:
%%wget -t 0 --retry-connrefused -c -N -S -T 16 -w 1 --random-wait --no-dns-cache -P /mnt/home/downloads --no-cache --no-cookies http://www.torproject.org/dist/tor-0.2.1.30.tar.gz%%
Enter the directory to which the source file was downloaded, in the above example it is ///mnt/home/downloads//:
%%(language-ref)cd /mnt/home/downloads%%
Unpack (extract) the source file (the source code is extracted to a directory called //tor-0.2.1.30//):
%%(language-ref)tar xfv tor-0.2.1.30.tar.gz%%
Enter this source code directory:
%%(language-ref)cd tor-0.2.1.30%%
Always read the README and INSTALL text files for any specific or special instructions.
If a //configure// script is available (look inside the source directory) features can be enabled or disabled. All the available configure options/arguments are listed by executing the following command (always do this since the options available can change with each new software version):
%%(language-ref)./configure --help%%
Execute the //configure// script with appropriate options/arguments which will generate a valid //Makefile// script file within the source directory (only use //-pipe// if >=512MB R.A.M. is available):
**%%(language-ref)./configure CFLAGS="-mtune=native -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" --prefix=/usr --sysconfdir=/etc --localstatedir=/var --host=i486-pc-linux-gnu%%**
If there are errors, and the script does not run to completion, this means that dependencies are missing and would need to be installed first before running //configure// again. For example, [[Tor]] has the dependencies [[libevent]] and [[openssl]] which means that these programs have to be installed __prior__ to running the //configure// script successfully, i.e. to completion.
Then build (compile):
%%(language-ref)make%%
and check:
%%(language-ref)make check%%
and optionally install the program:
%%(language-ref)make install%% (This is optional because one may first proceed to make a PET or SFS package before using it itself to install the software which is usually a more flexible way)
__The process is now complete__ (but this is not the whole picture). The program has been installed and it may be used if you know where the executable file is located (usually at ///usr/bin//). It may be found using the //which// command, e.g.:
%%which tor%%
The above explanation is a general outline. Not all source code will make use of the same configure arguments (options) as given above; many specific cases are provided in this wiki within the software category, e.g. [[libav]], [[pidgin]], [[transmission]].
For an idea of how complex compiling can become examine this [[http://www.murga-linux.com/puppy/viewtopic.php?p=503232#503232 midori]] case.
Some extra notes:
- use //prefix=/usr// and not //prefix=/usr/local// (for the sake of standardization and recommended by BarryK)
- a lot of //Makefiles// will leave the "add debug symbol" option of GCC enabled (it is "-g"). This means that a lot of "text" information is added to your program to facilitate debugging, making the program file significantly larger. When compiling open the //Makefile// and look for a line that sets the C flags (usually CFLAGS = ...). If //-g// is declared it may be deleted. However, there is no need since the //strip// command will remove all debugging information later.
- if the configure script is not available (rare) then this should mean that the //Makefile// script file already exists. (If it exists advanced users may edit it accordingly). If it exists execute the following: %%(language-ref)make CFLAGS="-mtune=native -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}"%% %%(language-ref)make PREFIX=/usr SYSCONFDIR=/etc LOCALSTATEDIR=/var install%%
- //-tune=native// is used when the program is to be used for microprocessors of the same type that was used to compile it
- //-tune=generic// is used when the program is likely to be used with any microprocessor; that is why software package maintainers often make use of it since their packages are going to be shared with many users
- //-tune=[[http://gcc.gnu.org/onlinedocs/gcc-4.6.0/gcc/i386-and-x86_002d64-Options.html#i386-and-x86_002d64-Options cpu-type]]//
- to un-install execute the following command (only possible if the source directory was not deleted and/or if the source code provides the facility to un-install) [**Warning**: this will un-install any pre-existing installations as well, from the same locations]: %%(language-ref)make prefix=/usr uninstall%%
- possible [[http://www.murga-linux.com/puppy/viewtopic.php?p=344270&sid=085ff07518550457453de18e810542c3#344270 LDFLAGS]]
Now try compiling these simple cases: [[x264]], [[libvpx]]; [[xvid]] (more demanding; must read INSTALL file)
Ideally one should proceed to create a PET software package from the compilation process. The PET is a special package that is manually created so that it can be subsequently used by any user to automatically install the pre-compiled software //and// any additional supporting files such as menu entries and optionally other customizations. Most users rely on these PET packages for acquiring additional software to their repository. After compiling, some manual tweaking is often required so as to have successfully running software, and that is one reason why PET packages are created since they will contain those modifications. To become self-proficient at software package creation it could take at least a year of practice.
==={{color text="Compile, install, and create the corresponding PET software package" c="black"}}===
First compile:
%%(language-ref)./configure CFLAGS="-mtune=native -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" --prefix=/usr --sysconfdir=/etc --localstatedir=/var --host=i486-pc-linux-gnu && make%%
N.B. If the package is intended for maximum wide distribution, then use //-mtune=generic// instead of //-mtune=native//.
Then install using either method (a) or method (b):
-(a) Installation to a temporary location
Install to a temporary directory ///dev/shm/program_name// for the specific purpose of creating a PET software package [N.B. this sometimes fails and so when the command is issued all the compiled files are installed into the Linux file system and nothing into ///dev/shm/program_name//. If installation at this time into the Linux file system is undesired, the personal storage save file //may// be deleted and a new one created with ease.]
%%(language-ref)make install DESTDIR=/dev/shm/program_name%%
Then use the //strip// command ([[strip a recent version]]) to reduce the size of executables and shared objects (see also [[Pstrip]]):
%%cd /dev/shm/program_name && strip -p -d --strip-unneeded -R .comment -R .note -R .note.ABI-tag program_name/*%%
- (b) //(for advanced users that are proficient at compiling only)// Either (i) or (ii)
(i) Installation to the //existing Linux file system// and simultaneously using the //new2dir// script which offers an option (//option 3//) to create individual packages for the compiled executable files, development files, and documentation files
%%(language-ref)new2dir make install%%
(ii) Installation to a //temporary location// and simultaneously using the //new2dir// script which offers an option (//option 3//) to create separate packages for the compiled executable files, development files, and documentation files (not always successful)
%%(language-ref)new2dir make install DESTDIR=/dev/shm/program_name%%
Then use the //[[dir2pet]]// script which converts a directory into a PET file, e.g. using tor-0.2.1.30 compiled within Wary:
%%(language-ref)dir2pet tor-0.2.1.30-w-20110318%%
The name given to the directory is arbitrary and user-defined, but should be appropriate and comprehensible since the resultant PET file will have the same name. For example, the above directory has been given a date suffix to denote the date of creation of the software package, and the suffix //w// to denote that it was compiled within Puppy Wary. Normally, for software applications one would create additional files to place inside the parent directory before executing //dir2pet// so that menu entries, and icons for the menu and desktop, are made available: see SoftwarePackageCreation
To un-install a PET software package use the Puppy Package Manager: //Menu > Setup > Puppy Package Manager//
These scripts may be useful for assisting with compiling: [[src2pkg]] and Pcompile (references: [[http://www.murga-linux.com/puppy/viewtopic.php?p=320609 1]], [[http://www.murga-linux.com/puppy/viewtopic.php?p=525706#525706 2]]).
==={{color text="Appendix 1" c="black"}}===
To convert Puppy into a complete compiler environment it is necessary to acquire and install a special SFS file that corresponds with the version of Puppy Linux that will be used for compiling. The file has "devx" in its name.
- [[http://distro.ibiblio.org/quirky/ Wary]]
- [[http://distro.ibiblio.org/quirky/ Quirky]]
- [[http://www.brainwavedesigncentral.net/micko01/stuff/puppy/spup/ Puppy 5.3]]
- [[http://distro.ibiblio.org/puppylinux/puppy-5.2.8/ Puppy 5.2.8]]
- [[http://distro.ibiblio.org/puppylinux/puppy-4.3.1/ Puppy 4.3.1]]
__For live CD/DVD and frugal Puppy installations__
- a personal save file has to exist first; at least 512MB in size and with sufficient free space
- place the devx SFS file at ///mnt/home//
- then use //Menu > System > ""BootManager""//
- then re-boot
__For full Puppy installations__
http://puppylinux.com/development/compileapps.htm
__Puppy 1 versions__
//usr_devx.sfs//
==={{color text="Appendix 2" c="black"}}===
__Test 1__
devx file is installed when the command-line interface displays:
%%(language-ref)
# cc
cc: no input files%%
__Test 2__
Save the following as test.c
If using Geany, set it to C and test compile first
/* Example C program */
int main()
{ int i;
for (i = 0; i < 50000; i""++"")
{
printf ("%d",i);
printf (" Puppy is Great\n");
}
return 0;
}
%%gcc test.c -o test && ./test%%
http://members.cox.net/midian/articles/ansic1.htm
==={{color text="Appendix 3" c="black"}}===
Compiling is the process by which a program written in a human readable format is converted to a computer executable format. Programs can be written in assembly language, which is almost "perfect" in the eyes of a computer, very close to binary code.
lda 02
sta #c000
lda #c001
cmp #c000
bne d000
But this is difficult to understand, in C it might look like this:
a=2;
b=c;
if (a != b){
my_subroutine();
}
This is easier to understand (high level language), a simple comparison of two numbers, and depending on the result (if they are different), a sub-program is executed. As computers do not understand "if" and don't have variables (C) but only a stack (assembler), the code must be translated from C to assembler or even better directly to binary code (assembler itself is not binary, but a very simple form of a "high level language" very close to binary code). This translation is "compiling". If you open the resulting "code" in a hex editor, you will only see binary code, values from 0 to 255 "wildly mixed".
==={{color text="Appendix 4" c="black"}}===
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
http://www.gentoo.org/doc/en/gcc-optimization.xml
-O2 option: smaller binary, faster to load from disk, less RAM usage, better cache usage in systems with moderate processor cache, higher reliability.
-O3 option: slight to moderate speed increase for some applications, higher memory (RAM, cache and disk) usage, longer load times from disk, very occasional problems with compilation; expect less than 1% improvement in *overall* execution speed. It could possibly make faster code but the applications that benefit from it are very few, usually image and video decoders and such. However the side effects, like larger binary size, affects everything. Larger binaries use more memory, load slower, cause more disc I/O, etc. So compiling a system with -O3 will have the effect that a few applications run slightly faster at the expense of the rest of the system running slightly slower and becoming less responsive. Linux caches regularly used programs and files in RAM (that's the "cache" part when you run free -m on the command line), so the program may only need loading from the hard disk once (depending on the program and computer usage). Therefore this is less of a problem on systems with large amounts of RAM. A large CPU cache also helps as it is better suited to larger binaries, so you are more likely to see some sort of speed up. So if you have a high end system, you will suffer less from the problems associated with -O3.
----
==Categories==
CategoryDevelopment
CategoryCompiling
