Originally Published: Tuesday, 18 January 2000 Author: Rob Thomas
Published to: learn_articles_firststep/General Page: 1/1 - [Std View]

Compiling Your Own Software, Part 2

This is a sequel to last week's Compiling Software article. This article will be a bit more complex than last week's. We will be discussing passing more complicated options to your configuration, what goes on behind the scenes during the building process, and what to do if something goes wrong.

First of all, I'd like to extend my thanks to everyone who sent me their comments on last week's Compiling Software article. Your feedback formed the basis for this second article. Secondly, I'd like to warn readers that this article will be a bit more complex than last week's. We will be discussing passing more complicated options to your configuration, what goes on behind the scenes during the building process, and what to do if something goes wrong.

The "configure" script, as you know, is the first step in building software. However, you don't have to stop with just simple "./configure". As we can see by passing the "--help" option, it is capable of a lot more.

Usage: configure [options] [host] Options: [defaults in brackets after descriptions] Configuration: --cache-file=FILE cache test results in FILE --help print this message --no-create do not create output files --quiet, --silent do not print `checking...' messages --version print the version of autoconf that created configure

There is, of course, a lot more to this command. Sometimes there are package-specific options that will affect the way your application runs. All of this will usually be covered in the README or INSTALL file.

If you are a non-root user (you may have a shell account, for example), and want to install your own software, a useful configure option is --prefix. By setting this, you can choose where you want to install software. It is also equally as useful if you organize your file system a certain way.

For example:

bash$ ./configure --prefix=/home/rob loading cache ./config.cache checking host system type...

And so forth. Now, when you type "make install", the package will be installed in /home/rob, my writable directory.

Another important thing to know when dealing with the configure script is what to do in case one of those libraries it's searching for doesn't turn up. For example, let's say we are building a gnome application, and our configure script cannot find gnome:

checking for gnome... no

Now it should give you an error, and tell you it couldn't find these libraries. There are two ways to go from here. If you know you have gnome installed, you'll have to specify where it is located. If you haven't installed it, it's time to do so. In this case, you'll be able to find all the information you need on installing gnome at it's website, http://www.gnome.org. However, if you know it's installed but don't know why the configure script didn't work, try this.

bash$ locate gnome /usr/local/gnome/lib/libgnome.so /usr/local/gnome/lib/libgnome.so.32

This will be followed by countless other entries, but from this we can see that gnome is actually installed in /usr/local/gnome. Now we'll try configure again, adding a special option:

bash$ ./configure --with-gnome=/usr/local/gnome

In the same way that we used --prefix= to specify where we wanted our software installed, we can specify where it can find the libraries it needs to build our software.

Sometimes, however, the configure file is not present, and neither is the Makefile. In this situation, it is always a good idea to run the following three commands:

bash$ aclocal, autoconf, ./autogen.sh

What this will do is generate the configure files for you, and execute the generation script that came with your software (if there is one). This should then go on with the configure process, and make you the Makefile you need to build your software.

Another problem you may run into is the lack of a "configure" file or a "Makefile" file. If there is a file called "Imakefile", however, you simply need to run "xmkmf", which will create a regular Makefile from the Imakefile. It would be run like this:

bash$ xmkmf -a

What the -a option will do is create all the Makefiles this package will need. You can now run "make" and "make install" like normal.

If there is no Imakefile, and the documentation (remember the INSTALL and README files?) are not helpful, the package you have downloaded may be incomplete. There is also a chance that it is a development copy, and should only be used by developers. In this event, your best suggestion is to find a binary.

Once you run the "make" command, the Makefile is read by make. The Makefile contains all the commands to build your software, and make runs them. For example, the Makefile has a list of what files need to be compiled (translated into object code), and which libraries they must be linked to. If, say, you were building a gtk+ app and did not have the proper gtk+ libraries specified in your Makefile, the build would fail with all sorts of errors. In any situation where you get errors, it's always a good idea to check the documentation again.

Now that we've compiled our application, it's a good idea to install it. This is usually done with a "make install", and you must be root to do it. This involves copying the compiled programs from the package's directory onto your system.

bash$ su Password: bash# make install

(and then watch the status scroll up)

Provided the install process does not return any errors, try running the application. If it works, you may now safely erase this directory, for your software has been installed, and has been tested.

Compiling your own software can be a large step for users unfamiliar with Linux or UNIX. However, with some practice and experience, the standard "./configure;make;make install" will be come second nature as you try the wealth of free software you have access to. Have fun!

By Rob Thomas - rthomas@linux.com