Setting up Puppy for compiling

Requisite reading: http://puppylinux.com/development/compileapps.htm

Compiling the kernel

http://puppylinux.com/development/compilekernel.htm

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 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.24.tar.gz

Unpack (extract) the source file (for tar.bz2 file formats use tar xfjv instead):
tar xfzv tor-0.2.1.24.tar.gz

The source code is extracted to a directory called tor-0.2.1.24. Enter this directory:
cd tor-0.2.1.24

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):
./configure --help

Executing the configure script will generate a valid Makefile script file within the source directory. Suggested environment variables to use are CFLAGS="-mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" (only use -pipe if sufficient R.A.M. is available). The standard configure options used are --prefix=/usr --sysconfdir=/etc --localstatedir=/var:
./configure CFLAGS="-mtune=generic -march=prescott -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" --prefix=/usr --sysconfdir=/etc --localstatedir=/var

Then build (compile)
make

and (optionally)
make check && make test

and install your program (if you wish to create a .pet software package simultaneously read the next section)
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.

Some extra notes:
make CFLAGS="-mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}"

then
make PREFIX=/usr SYSCONFDIR=/etc LOCALSTATEDIR=/var install

make prefix=/usr uninstall

Summary: compile, install, & create the corresponding .pet software package

Enter into a terminal (console)
./configure CFLAGS="-mtune=generic -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" --prefix=/usr --sysconfdir=/etc --localstatedir=/var

then compile (build)
make

then install compiled files and simultaneously create new directory for software package creation
new2dir make install

then change to parent directory for .pet software package creation
cd ..

then execute the dir2pet script which converts a directory into a .pet file, e.g. using tor-0.2.1.24 compiled within Puppy 4 (p4)
dir2pet tor-0.2.1.24-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: SoftwarePackageCreation

To un-install a software package use the Puppy Package Manager: Menu > Setup > Puppy Package Manager

Appendix


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 liveCD/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

How to test if devx_XXX.sfs is installed
Quick Test
Open up rxvt and type 'cc' it should output this back
cc: no input files

If it tells you 'command not found' then it has not installed properly.

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

What does Compiling mean?
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 hexeditor, 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 liveCD does not come with the compilation tools. For that you will need the file devx_XXX.sfs. [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.

# To install the usr_devx.sfs do the following: Go to this download page and download the devx_201.sfs (http://www.puppyos.com/test/∞) or (http://www.puppylinux.org/user/downloads.php?cat_id=12)
# Copy the downloaded file to the same place where your pupxxx.sfs file is located (e.g. pup001.sfs for puppy 1, pup_200.sfs for puppy 2.00, pup_201.sfs for puppy 2.01...). Or in a Hard Drive installation to the / folder. Or in /root on a liveCD.
# Reboot puppy.

or try this explanation

Puppy has a full gcc make/compile/link suite, available as a scrunched file system. It builds most Linux packages from source using the standard "./configure", "make", "make install" incantation.

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∞; )

To use it, put the devx_xxx.sfs or usr_devx.sfs file in the same place as your pup_save file, and reboot.

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. Google 'man ldd linux'. The command is available in Puppy, though the man page is not. As it displays a list of all packages required, and you are probably most interested in just those 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'
Example with results:
ldd `which mplayer` |grep not
libsmbclient.so.0 => not found

Of course you could type in
ldd /etc/local/bin/mplayer

substituing your app and its path for /etc/local/bin/mplayer, and scan the resulting list manually

Optimizing
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 next and most common flag is the '-pipe' option. 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.

-O2 or -O3?
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.

What effects -O3 has
-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.htm
http://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



Categories
CategoryDevelopment
CategoryHowTo
CategoryPuppyDocumentation

There are no comments on this page. [Add comment]

Valid XHTML 1.0 Transitional :: Valid CSS :: Powered by WikkaWiki , online since July 19, 2009.