PuppyLinux : Compiling

• Categories
• PageIndex
• RecentChanges
• RecentlyCommented
• Login/Register
• Search:

Setting up Puppy for compiling

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 for a particular piece of software is converted into a binary package which a computer can make use of. This is achieved by using the make command. Prior to issuing this command, some configure options are passed to it by running the configure script (if it exists). If there is no configure script this means that there are no configure options available and one proceeds directly to issuing the make command.

Begin by changing to your chosen download directory, for example /tmp, by clicking on the "console" desktop icon and typing:

Download the source tarball. Using tor as an example:

Unpack (extract) the source file:

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

Read the README and INSTALL text files for any specific instructions for the software in question.

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 are listed by executing the command (always do this):

Executing the configure script will generate a valid Makefile script file within the source directory. The standard environment variables used are CFLAGS="-mtune=i486 -O2 -pipe -fomit-frame-pointer" CXXFLAGS="${CFLAGS}" (N.B. BarryK does not use any environment variables; technosaurus' environment variables) and the standard configure options used (recommended by BarryK) are --prefix=/usr --sysconfdir=/etc --localstatedir=/var :

Then build (compile)

and install your program

If the configure script is not available then this should mean that the Makefile script file already exists, so edit it accordingly; otherwise execute the following:

then

Use prefix=/usr and not prefix=/usr/local

To uninstall (only possible if the source directory was not deleted) execute the command [Warning: this will uninstall any pre-existing installations as well, from the same locations]:

Summary: compile, install, & create the corresponding PET software package

Enter into a terminal (console)

then compile (build)

then install compiled files

then change to parent directory

then execute the "dir2pet" script which converts a directory into a PET file, e.g. using tor-0.2.1.19 compiled under Puppy 4 (p4)

To uninstall a software package use the Puppy Package Manager:
Menu > Setup > Puppy Package Manager

Appendix

(some sections need revising)

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 Puppy 4.3.1 the corresponding file would be devx_431.sfs

For Dpup the corresponding file would be dpup-devx-XXX.sfs

For Quirky the corresponding file would be quirky_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

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.

Why Compile programs?
Sometimes you will find that a program or driver that you need or want is not available for Puppy. The good news is: If that application or driver is open source, you will have access to the source code to compile, but don't get put off by the long words. These days most open source applications have a very simple way to compile and install from source code.

Puppy 2
If you're running a liveCD or frugal/poor-man's/option-1/coexist install, stick the devx file in /mnt/home, in the same directory as pup_save.3fs.

If you do have one of the latter two, did you say you were putting it in /root? If so, and that doesn't work, try / instead. As in the actual root, not /root.

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 (thanks for MU, or was it Lobster, who pointed out this simple trick... I like being lazy).

Optimizing
Basic (safe) optimizations
There are several basic optimizations considered safe for general use. The first is -O (letter, not number). To see exactly which optimization flags are enabled at each of the optimization levels, as well as a list of of other optimizations that can be enabled, please read the GCC man page or the online documentation.
-O
-O turns on some basic optimizations that don't greatly impact compile speed, and will greatly increase the speed of your system. Though there is usually no reason to use -O instead of -O2.
-O2
-O2 turns on all -O optimizations and all other optimizations that don't greatly increase binary size or interfere with debugging. -O2 is even better than -O, and usually just as safe. This is the optimization level most commonly used for packages and distributions in the Linux world and for the Linux kernel. If you want a fast system that "just works", -O2 is probably good for you.
-O3
-O3 turns on all -O2 optimizations and also some optimizations that increase binary size and make debugging harder or even impossible. Using -O3 as your default optimization level might be a bad idea, see below.
-Os
-Os optimizes for size. -Os enables all -O2 optimizations that do not usually increase code size and performs further optimizations designed to reduce code size.
-Os is very useful for large applications, like Firefox, as it will reduce load time, memory usage, cache misses, disk usage etc. Code compiled with -Os can be faster than -O2 or -O3 because of this. It's also recommended for older computers with a low amount of RAM, disk space or cache on the CPU. But beware that -Os is not as well tested as -O2 and might trigger compiler bugs.
Note that only one of the above flags may be chosen. If you choose more than one, the last one specified will have the effect.
-fomit-frame-pointer
-fomit-frame-pointer tells gcc to omit frame pointers, freeing up an additional register on the CPU. This is mainly useful on x86 as most other arches, like AMD64, have it on by default at -O2 or greater, though binary size may increase slightly. This flag breaks debugging on x86 and possibly other arches unless you're compiling with gcc 4.x and the -fvar-tracking flag.
Glibc has a glibc-omitfp USE flag. This makes glibc use -fomit-frame-pointer and some other optimizations for the build where it's safe. To read more about optimising glibc try this HOWTO.
-march=
-march tells gcc to optimize for a certain architechture. Basically, you just need to know what your CPU is, and the GCC name for it. Remember that this breaks compatibility with older arches!
This flag takes the following form:
-march=pentium4
Of course you want to replace pentium4 with whatever CPU you're actually using.
Here's an incomplete list of valid x86 architectures you may use with the -march flag:
i386, i486, i586, i686, pentium, pentium-mmx, pentiumpro, pentium2, pentium3, pentium-m, pentium4, prescott, k6, k6-2, k6-3, k8, athlon, athlon-tbird, athlon-4, athlon-xp, athlon-mp, athlon64, opteron, winchip-c6, winchip2, c3
Check the gcc manual page for a complete list (under Hardware Models and Configurations).
Note: "-march" implies "-mtune" (see gcc manpage).
If you are using gcc-4.2.2 or newer you can also use
-march=native or -mtune=native.
See gcc doc. This comes especially handy if you have an Intel Core* CPU and are planning swiching between gcc-4.2 and gcc-4.3.
-mtune=/-mcpu=
-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/-mcpu 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.
-pipe
The final 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?
This intends to be a balanced appraisal of the merits of running either of these optimizations. Generally with those running Gentoo Linux, the choice falls between these two. There is a lot of discussion over the merits of each optimization level, with data showing better performance one way or the other. This is especially true with these two. This should not tell you which is best, there is no straight answer, it ought to merely inform you of the merits and faults of the two optimization levels. As always, use the CFLAGS best suited to your computer and how you intend to use it.
Some general pointers
If you're a Newbie to Linux, it is recommended to run -O2, you can always experiment later.
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.

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 you should open 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.

Barry uses:

Some use:

References

http://puppylinux.com/development/compileapps.htm
http://murga-linux.com/puppy/viewtopic.php?t=52033

---

Categories

CategoryDevelopment
CategoryHowTo
CategoryPuppyDocumentation

• [Source]
• [History]
• 2010-02-05 10:03:16
• Owner: coolpup

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