I have only been using Linux for about three years, but I love it; the idea of Open Source, community, freedom, etc. I have found many topics concerning using and configuring Linux for which the documentation is either outdated or non-existent.
One of these things is compiling and installing software from source code. This was a complete mystery to me for the first year that I used Linux, being that every distribution that I had been using (every dist. had features that I liked and features that I did not like) was a Redhat based distribution (Redhat, SuSE, Linux-Mandrake, etc.), I had been spoiled with *.rpm (Redhat Package Manager) software installations.
I used to wait until an *.rpm was released for any software that I needed. It was only when I became more familiar with the Linux file system and structure that I decided to again try my hand with installation from source code. It was about the same time that I had decided that I wanted to be able to use the freshest version of some of the software available. It was then, after a little research, that I discovered that installing from source is not nearly as difficult as I had suspected.
There are many reasons why one would want to install a program from source rather than a binary release. The first reason involves optimization. How efficiently a program utilizes the system depends entirely on the hardware that comprises the system and whether or not the software is configured to use all of the features of the hardware.
Software compiled for an i386 processor should run on any Intel based processor released after an i386, however it will not be able to utilize the newer features of the newer chip and, thus, will not run as well as if it were compiled for a newer chip. Different processors have a different extended (extended in this context means in addition to the base instruction set, which would be that of an i386 processor) instruction sets at the machine code level.
Most compilers will optimize code for a specific CPU type when you compile it, so that it will run faster and more efficiently by using these extended instruction sets.
Another reason to compile software rather than install from binaries is to stay on top of the latest releases. The source code will almost always be released before binaries for the same software.
One nice thing that many developers will do is release a nightly “snapshot”. This is for software that is actively being developed and will often times offer bug fixes and additional features that the most current stable release may not have. This will usually be alpha or beta software, however that is half the fun, isn’t it?
What is the first thing to do? Download the compressed software package to /usr/src/ and extract it to a directory. I like to use /usr/src/ for all of my source code, that way I know where it all is and it is right there with the source code for my kernel(s). You can download via FTP or HTTP, so long as you are downloading in a manner that does not affect the file.
Most source files will end with *.tar.gz although a newer type compression uses *tar.bz2 . Personally, since I am a relatively new convert to Linux from windoze, I use the KDE2 desktop and archiver to extract all of my compressed files (again, to the /usr/src/ directory).
If you are running a box without X or you prefer the command line, open up your favorite shell (I prefer BASH, which is the default Konsole in most distributions):
For a *tar.gz source file named foo.tar.gz, type: tar -xvf foo.tar.gz
For a *tar.bz2 source file named foo.tar.bz2, type: bz2cat foo.tar.bz2 | tar xvf –
For more specific switches for the compression utilities, see the MAN pages for each (i.e. type ‘man tar’ at the command line followed by pressing enter). Most software will have installation instructions published on their site that will cover any additional switches and/or configuration options that you may need to be concerned with.
Once you have extracted the source you will need to “cd” to the root of the source directory. In other words, if the software was named “foo” you would type cd /usr/src/foo at the command prompt (assuming of course that you extracted the source to the /usr/src directory). As I mentioned previously, I use KDE2, so I would normally just browse to that directory.
Konquerer, KDE’s browser, has a really nice feature in that you can enable a command prompt (Konsole) window as part of the browser. This is a really nice feature for those of us who are used to graphical interfaces. With this, I can browse, copy, paste, extract (by right clicking the compressed file and opening it with Archiver), etc. with my normal GUI devices and yet, when I do need to issue a command from the command line, I still can without the need to open up a new Konsole.
Once you are in the root directory of the software that you want to install, open up any “install”, “readme”, etc. files in your favorite text editor, and read them. If they contradict anything that I say from here on out, follow those directions, not mine.
Open up a command prompt in the root directory of the software. The first thing you will generally have to do is type (followed by pressing enter):
In some instances (being that the “configure” file is actually a script) you may have to type:
sh configure (press enter)
This line initiates the configuration script that will usually check for any libraries that are needed, whether you have a functioning and compatible compiler, file system structure and anything else that will be required to build and install the software. As the configuration script runs, you will usually see many lines of output that will show exactly what the configuration script is looking for.
If you receive any errors while running the configuration script, you can check what it was that failed and take steps to correct the problem or problems that you may have encountered (based upon the output of the configuration script). Occasionally the configuration script will require that you pass options to it. The best way to determine what options and values you may have to pass to the script is to type:
If you are good at scripting, you can often times change the configuration script to better suit your needs. I am not that gifted (yet). If you do make changes in the script that help you, please forward these changes to the maintainers of the software. I am sure that if you have this problem, many others will have had the same problem. This is the beauty of Open Source software and the reason why Open Source software progresses so quickly.
If you made it this far (piece of cake, right?), you are now ready to compile the program. For those that don’t know, compiling is the process of taking human readable source code and making it into a binary file or files that the computer knows how to use. There are actually several processes that occur at this point, but unless you intend to become a developer these processes are more or less trivial. Any way, to compile all that you have to do is type:
make (followed by pressing enter)
If you have a multi-processor machine, you can make use of the extra processor(s) by telling make to use more processes. This is done with the -j switch followed by the number of processes you would like ‘make’ to utilize. Be careful with this, if you specify more processes than your machine can handle, you will get errors. Here is an example of how I would run ‘make’ on a dual processor machine that is not busy doing several other things:
make -j 2
This will utilize 100% of both processors on a dual processor machine. In other words, this is not something to do on a machine that is handling other tasks.
In some instances (usually those in which you have no configuration script) you may have to pass options to ‘make’. If this is the case, be sure to read all of the documentation for the software; these values are usually very specific in regards to your system. If you get errors when you run ‘make’, be sure to read the documentation and make sure that you did or did not need to pass options to ‘make’.
If you did get an error during compilation, simply run: ‘make clean’ (followed by pressing enter), or if you really want to return the source to “virgin” status (i.e. you tried ‘make clean’ and still returned errors during compilation and you want to verify that it had nothing to do with previous compilation attempts) you can try: ‘make distclean’.
In order to install the binaries, you will need “super-user” privileges. If you have not already logged in as root, simply type ‘su’ (followed by pressing enter). You will then be prompted for the ‘root’ password. Enter that followed by pressing enter and you are ready. Simply enter ‘make install’ and make sure that you receive no errors. That is it. You are done!
All that you should have to do to run the program is to type its name followed by pressing enter. On occasion, some programs do not install to the normal places and you will have to create symbolic links to them. Symbolic links can be thought of as shortcuts, for you Windoze folks. Normally when this happens, the executable is put into a folder called ‘bin’ (short for binary) in the root of the software source folder.
In our example, the root of the source folder is ‘/usr/src/foo’ so we would need to cd (or browse) to ‘/usr/src/foo/bin’ to see if the executable is there. If it is there, it is probably called ‘foo’. If that is the case we will want to create a link to it in ‘/usr/bin/’ so that all users will be able to run the program. To do this, simply type (substituting your actual file and directory path names for ‘foo’):
ln -s /usr/src/foo/bin/foo /usr/bin/foo
If, at a later time, you decide to uninstall the program, most software that is distributed as source will have a ‘make uninstall’ option to remove the program. Simply ‘cd’ to the root of the source folder and type ‘make uninstall’.
I hope that this article has helped reduce some of the intimidation involved in installing software from source code.
Jay Fougere is the IT manager for the Murdok network. He also writes occasional articles. If you have any IT questions, please direct them to Jay@https://murdok.org.
