Introduction

Many people might wonder why you would want to compile source code. After all, most Linux programs can be had by simply opening up their favorite package manager and clicking "install". The package manager does the rest. However, there *are* reasons why you would want to do this. For one thing, some Linux programs are only distributed in source code. Or maybe they don't distribute packages for your Linux distribution. In any case, you'll need to compile it.

Now compiling source code isn't the easiest thing. You need to have lots of libraries and other junk installed, need to know the right compilation syntax, and how to deal with errors when they come up. If this is scaring you, rightly so. I prefer installing packages with a package manager, too, so if that's an option for you, I suggest doing that instead. (In case you're wondering: here's my Linux packages tutorial.)

What you'll need

On your Linux system, you're going to need to have the command line software development tools installed. This includes gcc, g++, automake, and others. You don't actually need the Gnome and KDE development tools, as you're going to be using the command line for most of the compilation.

Getting the source code

To start off, you'll need to download the source code for the particular application you plan to use. How do you know if what you're downloading is source code? Look at the file extension. If it ends in the most common extensions, .tar.gz or .tar.bz2, you can be nearly guaranteed that the archive you're downloading contains the program's source code.

Extracting the source code

Once you've downloaded the file, it's time to extract it. Although you could use the graphical UI tools to extract the package, we're going to be needing the command line to compile it anyway, so it's just as easy to do it at the shell. So open up Konsole or whatever terminal application you use, and get ready to enter commands!

Depending on the file extension, you're going to be needing different methods of decompressing it. If it's a .tar.gz file (most common), enter the following:
Replacing myprogram.tar.gz with the name of the file you downloaded.

And if it's tar.bz2, it's equally easy:

The files will be extracted into the current directory, but that's usually not a problem, since most program's source code is encased in a single directory. Now you need to change into this directory. First of all find the name of the directory:
A directory usually with the name based on the archive would be here. Make this the active directory:

The actual compilation process

This is where the real fun begins. Now you need to turn the source code into an actual binary which the computer can run, so here's how you do it.

Compilation for newbies is usually described as "./configure make make install". It's a series of commands which under many circumstances, will compile the code without any errors. Here it is:

Here is how it works:

The ./configure command is actually a script that comes with most Linux programs. It looks at your hardware, the packages you have installed, and determines what will be needed to compile it. It then generates a unique makefile, which is a file containing a list of commands to the compiler. There's various options you can send configure; for a full list run configure with the --help option.

The "make" command is actually a *nix utility that is installed on most machines. What is does is look for a makefile generated from a configure script, and it runs it. This in turn runs the compiler, which then proceeds to compile your source code.

Finally "make install" uses the make utility, but for a different purpose. It looks at the makefile and copies the files generated by the compiler to system-wide directories so that all users have access to the program. That is why you need root access to run it. However, in many cases the program does not have to be installed, and can simply be run from the directory it was compiled in. In such a case, it's your choice whether you want to install it or not.

The errors-solving process

Undoubtedly, you'll get errors when you try to compile. This is quite normal and to be expected. There's usually nothing wrong with the source code however, so don't bother contacting the project's developers for help, because it's unlikely you'll get any.

The first thing to do when you get an error is to read the README or INSTALL file that came with the source code. (Which is actually what you should read first, but I never do . Don't worry, it doesn't hurt anyone.) It will usually contain installation instructions, and other requirements in order to compile the code.

Most often, your system is lacking libraries. These usually result in compilation errors such as "libjpeg not found" and derivatives. Usually the documentation describes which libraries you need, so set about to installing them. Although you *can* compile these packages if you want to, you usually end up on a wild goose chase, as this source code has dependancies of its own. The best thing is usually to open up your package manager and download the files yourself.

Try again, and then see if the errors went away or changed. If the system cannot find ./configure, you may have gotten one of those odd packages which contain no configure script. Check the project's documentation for more details.

Another resource you can use is Google. If you're having errors, it's highly unlikely that someone else hasn't had these errors too, at some point or another. So try googling the compilation errors, or parts thereof, and see what turns up. You might be surprised.

Last but not least, don't forget the community support. DaniWeb is a great forum for asking for help, and it's likely I'll see your problem if you post in the *nix forums. So don't kill yourself trying to compile a program.

Conclusion

Although compiling programs isn't something that we all enjoy, many things can be learned from it. You can get a better understanding of how programs are put together; learn how to optimize programs for best performance, and how to do regular system tool maintenance.

I could only cover the basics here, so to get a better understanding of how ./configure works and make work, follow the links below.

• How to compile software on Debian Linux

• Compiling Linux software

• Compiling software

--Joe

use this links to find the best results

http://linuxera.com/content/view/199/2/ http://linuxera.com/content/view/200/2/ http://linuxera.com/content/view/201/2/
jay

Thanks. Thats a great tutorial. I gave you some rep. You should submit it to davey for the tutorials section.

Great tutorial Joe

I'll just add that on Debian (based) systems you may want to use 'checkinstall' (available via apt) rather than 'make install'; it will create a .deb and allow you to remove/upgrade/distribute the package using debian's standard package management tools.

Nice and useful tutorial. Although a full list of the tools generally needed for source installations would be appreciated (hate to get that sanity test failed msg).

Especially if you make a small distrib-dependant list

Actually, it *was* in the tutorial section before Davey moved it into a thread during the process of redoing the tutorials. Maybe he thought it would serve more use here in the forums, rather than in the tutorial section.

Thanks for the tip, as you can tell, I haven't compiled a ton of software on Debian systems. My goal was to make this more of a generic-compilation guide, however, if I ever decide to rewrite the tutorial, I will definitely keep this improvement in mind.


I assume too much. Fortunately, the vast majority of the Linux distributions out there package the compilation tools into one complete deal, eliminating the hassle of installing each one separately. And the people who do use custom distros like that usually have the knowledge of compilation (hopefully), so it's not too bad. But again, I will definitely take this suggestion into consideration if/when I rewrite this tutorial.

well actually not only that the standard distributions aren't always full, especially when people who do not want to d/l too much just use netinst CDs, but there's always a chance some unusual compiler would be missing. also, in rpm distros and in deb based systems the names of the packages slightly differ. so while I can apt-get install libstdc++, I have to yum install compat-...blah..blah..blah etc
so knowing these things would be of great help, at least to me.

the same also goes for perl modules - while in many distribs you just have to use CPAN, in debian apt-getting lib-something-perl is easier and usually more efficient than installing and compilig Perl::Module through CPAN

reasons for compiling
people do want to install because there is no other way, but thats by far not the only or greatest reason, other reasons could be that they want the code to be optimised for their particular architecture and note that installing from source gives greater (if not full) control over the installation options, paths and fine tuning of the application.

tar, gunzip and bunzip2
my first note here is to the -f switch, it must come last in the list as it means file, your posts command would therefore produce:-

tar: z: Cannot open: No such file or directory
tar: Error is not recoverable: exiting now

but you probably allready knew this i would hope and just overlooked it

also note that while using 'tar -xvzf filename.tar.gz' (or .tgz or .Z) and 'tar -xvjf filename.bz2' as an authorative method will work most of the time, the programs gzip (gunzp) and bzip2 (bunzip2) are used by tar as external calls and are not implemented in all *nix's offerings of tar. therefore i suggest using:-

gzip -cd filename | tar xvf -
gunzip -c filename | tar xvf -

what you'll need
you can add 'make' to that list too as it is absolutely necessary.
as a note to non-linux users, noteably *bsd, you need to use gmake instead when compiling linux code. (i added this remark purely to make it obvious that linux code can be compiled on other *nix too)

also you have to read, minimally, the INSTALL file *BEFORE* progresing and as you said you don't, then allready i can see why your getting all those errors.
the way i do it is find out what dependancies (if any) there are, get them first, then read the INSTALL, do whatever pre-configuration is necessary and then start the compilation procedure. this saves time and frustration

compilation process
'make install' is not a part of the compilation process, it is the installation process, rather obvious you might think, but people will see this as a necessary step to making the program work. it should be noted that after having successfully run 'make', you can try out the software to see if it really is working ok and to give you a chance to evaluate wether or not you really want to 'make install' it.

overall an excellent post joeprogrammer, hope to see more good stuff in the future

>my first note here is to the -f switch, it must come last in the list as it means file
Most *nix boxes I've worked with don't really care about the order too much. However, you are correct, the -f switch should have been last.

>you can add 'make' to that list too as it is absolutely necessary.
Yep.

>also you have to read, minimally, the INSTALL file *BEFORE* progresing
I tend to find that reading the compilation guide after testing it out is faster; by the time I've failed the compilation I already know which library(s) I need to install. But again, that's not the "politically correct" method. ;-) I'll probably change this in a future revision.

>'make install' is not a part of the compilation process
Correct. I clarified this in the explanation, but it *should* technically be in its own section. Thanks for pointing that out.