Setting up Puppy for compiling
http://puppylinux.com/development/compileapps.htmCompiling the kernel
Compiling software applications
Compiling refers to when the source code, written by a human, for a particular piece of software is converted into a binary package which a computer can interpret or make use of. This 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.Begin by changing to your chosen download directory, for example /tmp. Open a terminal or console, by, for example, clicking on the "console" desktop icon and typing:
cd /tmp
Download the source tarball of the desired program, either as tar.gz or tar.bz2 file formats. Using Tor as an example:
wget -c http://www.torproject.org/dist/tor-0.2.1.26.tar.gz
Copy the source file to a working directory:
cp tor-0.2.1.26.tar.gz /tmp
Enter the working directory:
cd /tmp
Unpack (extract) the source file:
tar xfv tor-0.2.1.26.tar.gz
The source code is extracted to a directory called tor-0.2.1.26. Enter this directory:
cd tor-0.2.1.26
Read the README and INSTALL text files for any specific or special instructions.
If the configure script has been made available to you (look inside the source directory) features can be enabled or disabled. All the available configure options/arguments are listed by executing the command (always do this since it is educational):
./configure --help
Executing the configure script with appropriate options/arguments will generate a valid Makefile script file within the source directory. Recommended environment variables to use are CFLAGS="-mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" (only use -pipe if >512MB R.A.M. is available). The standard configure options used are --prefix=/usr --sysconfdir=/etc --localstatedir=/var:
./configure CFLAGS="-mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" --prefix=/usr --sysconfdir=/etc --localstatedir=/varThen build (compile)
make
and (optionally)
make check && make test
and install your program
make install
The process is now complete. 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:
which program_name
If desired one could proceed to make a pet software package which is a special package that is manually created so that it automatically installs the compiled files and any additional supporting files such as menu entries and other customizations. Most users rely on these pet packages for acquiring additional software since they do not know how to compile the source code. This web page has been created to encourage them to acquire that skill.
Some extra notes:
- Use prefix=/usr and not prefix=/usr/local (for the sake of standardization)
- 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 the line includes -g remove it and see how much space is gained.
- 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:
make CFLAGS="-mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}"then
make PREFIX=/usr SYSCONFDIR=/etc LOCALSTATEDIR=/var install
- 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]:
make prefix=/usr uninstall
Compile, install, and create the corresponding pet software package
First compile:./configure CFLAGS="-mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" --prefix=/usr --sysconfdir=/etc --localstatedir=/var && makeThen install using (a) or (b):
- (a) Installation to a temporary location
make install DESTDIR=/tmp/program_name
- (b) Either (i) or (ii) (for advanced users only)
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)
new2dir make install DESTDIR=/tmp/program_name
Then use the dir2pet script which converts a directory into a pet file, e.g. using tor-0.2.1.26 compiled within Puppy 4 (p4)
dir2pet tor-0.2.1.26-p4
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
Appendix 1
To convert Puppy into a complete compiler environment it is necessary to acquire a special sfs file that corresponds with the version of Puppy Linux that will be used for compiling.
For Quirky the corresponding file would be quirky_devx_XXX.sfs
For Puppy 4.3.1 the corresponding file would be devx_431.sfs
For Dpup the corresponding file would be dpup-devx-XXX.sfs
For live CD/DVD and frugal installations save or copy the file to /mnt/home (if it does not exist then you probably have a full installation, see below). If you have not yet created a pupsave file you will need to do that first; then re-boot; Puppy is now able to recognize the devx file and you may start compiling.
For a full installation:
http://puppylinux.com/development/compileapps.htm
Appendix 2
How to test if devx_XXX.sfs is installed - Quick TestIt is installed when the terminal displays:
# cc cc: no input files
Better Test
Save the following as test.c
If using Geany, set it 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;
}
In the same directory open a terminal window (Right-click in the open folder/directory and select Window/Terminal Here)
and type
gcc test.c -o test
this will create a runnable file called "test"
the command
./test
will run it . . .
find a good tutorial e.g.
http://members.cox.net/midian/articles/ansic1.htm
Appendix 3
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". The computer can understand this code, but no human can.
The Puppy LiveDVD does not come with the compilation tools. For that you will need the file devx file. [Note that Puppy 2.00 requires devx_200.sfs, Puppy 2.01 requires devx_201.sfs, etc. This is the naming convention for all extra sqaushfs files that allows Puppy to recognize them. Puppy 1 versions use usr_devx.sfs, which does not follow this convention.]
The devx_201.sfs is not a standard requirement in Linux. It is just a clever way Barry (Puppy's creator) found to package all the development tools in an easy to install package. This package includes the tools, libraries and header files required to compile applications.
The development environments for Puppy 2.00 and 1.xx are available at http://puppylinux.org/user/downloads.php?cat_id=12 . devx_201.sfs is at http://www.puppyos.com/test/∞; (and at my mirror page: http://s3.amazonaws.com/puppy/index.html∞; )
Your application may have other dependencies. Make sure that those dependencies are present in Puppy or that you compile them before trying to compile the application. The ldd command is useful here. As it displays a list of all packages required, and you are probably interested in just those that are missing, try
ldd `which mplayer` | grep not
Note that the ` on each side of mplayer is a back quotes above the tab button, not regular single quotes. This tells it to run the ldd command on the results of the which command, so you don't have to first locate mplayer (in this example - replace mplayer with the program you wish to check dependencies for), the results of which are piped through the grep command which only lets through the results containing the word 'not':
# ldd `which mplayer` | grep not libsmbclient.so.0 => not found
Appendix 4
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html-mtune, or -mcpu in older versions of GCC, is similar to -march and accepts the same options. Unlike -march it doesn't break compatibility with older arches. -march and -mtune options can be mixed to get the desired effect. If you aren't going to share your binaries with other computers you don't need this flag and should only set an appropriate -march instead. The exception is arches like PPC where -march isn't available. If you use -mtune instead without any -march option, your binaries are backward compatible down to i386, but the scheduling is optimized for your chosen architecture. CPUs are also backward compatible so if you update your system with a new CPU you can still use your old packages.
The '-pipe' option tells GCC not to create temporary files when compiling, and instead pipes data directly to the next function, which saves some compile time. Be aware that using -pipe will cause GCC to use more RAM so don't use it if you have very little.
If you are running a server it is recommended to run -O2, system reliability might suffer with -O3. If you want a system that just works it is recommended to run -O2. If you are running a legacy (pentium equivalent, or older) check out -Os above, this is generally recommended due to these chips' exceedingly small (by modern day standards) cache size.
It is very easy to get a system built using -O3 instead of -O2. A lot of packages that break with -O3 already replace the flag with -O2. -O3 could be used by those feeling a bit more adventurous and willing to experiment/get their hands dirty.
-O3 makes debugging a lot harder, and so should not be used if you intend to do programming or developing. For this, and other reasons, most Linux developers use -O2. The kernel is compiled using -O2. This is not affected if you place -O3 in your CFLAGS.
-O3 is the highest optimization level and 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.
The choice summarized:
-O2 smaller binary, faster to load from disk, less RAM usage, better cache usage in systems with moderate cpu cache, higher reliability;
-O3 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.
References
http://puppylinux.com/development/compileapps.htmhttp://murga-linux.com/puppy/viewtopic.php?t=52033
http://www.gentoo.org/doc/en/gcc-optimization.xml
http://gcc.gnu.org/onlinedocs/gcc/Optimize-Options.html
http://www.murga-linux.com/puppy/viewtopic.php?p=344270&sid=085ff07518550457453de18e810542c3#344270
