Troubleshooting ./configure, make and make install Tutorial

Sometimes, the typical sequence to compile a program doesn't work. It starts spitting out all kinds of errors and seems to do everything but compiling that annoying program already. What to do then? This tutorial describes how to get rid of many frequently occuring errors during a typical Linux compiling sequence.Note: You should only compile software when you really need to do it. Compiling can be dangerous to your Linux installation. If you want to install some software, please look for a precompiled package (like a .rpm or a .deb) first. If you really need to compile, do it with care.Note: This tutorial assumes that you have some linux command line knowledge and that you know how to work with your distro's package manager.We can divide the errors in three categories:

• ./configure errors
• make errors
• make install errors

It should be quite obvious how to recognize them: ./configure errors are outputted by the configure script, make errors by the make command and so on. I'll now list common errors, with solutions, in these three categories.

./configure errors

The following list contains some common errors that ./configure can give, sorted by frequency of appearance. The first one is the most occuring one. Things between ( and ) are optional, they do not always appear. A bold italic OR indicates that multiple errors have the same solution. Text between < and > describes the kind of string that should appear on that place.

1. (configure:) (error:) <somename> (<someversion> (or higher)) not found. (Please check your installation!) OR checking for <somename>... (configure:) (error:) not found. OR (configure:) (error:) <somename> (<someversion> (or newer)) is required to build <package-you're-trying-to-compile>
   • This usually means that the -dev or -devel version of the package with the name <somename> is not installed on your computer. Please use your distro's package manager (or any other method to find and install packages) to search for <somename> and install, if possible, the -dev or -devel version.If the -dev or -devel version is already installed, or if it doesn't exist, have a look at the version number currently installed. Is it high enough? If it is lower than <someversion> (if applicable), try upgrading the package. If that is not an option for you, you can also try compiling an older version of the package you're trying to compile. Older releases generally use earlier version of the libraries / programs they depend upon.If the package that ./configure cannot find is a library (usually indicated by the package name being lib<something>), and you're sure you've got the right version installed, try to find the location where the library's files are located. If this directory is not included in your ld conf file (which is usually located at /etc/ld.conf or /etc/ld.so.conf) you should add it, and run ldconfig (usually located at /sbin/ldconfig). Please note that ldconfig should usually be executed with root permissions. If you don't know how to do that, have a look at the first point of Make install errors.Note: If you don't have access to the ld conf file, you can also add the directory to the LD_LIBRARY_PATH variable. This is pretty ugly and not quite the best practice, but sometimes you don't have any other options. You can add the directory to LD_LIBRARY_PATH this way:

     [rechosen@localhost ~]$ export LD_LIBRARY_PATH="$LD_LIBRARY_PATH:/your/library/directory"

     Of course, replace /your/library/directory with the applicable directory in your case. Note that the LD_LIBRARY_PATH will also have to hold /your/library/directory when running the program you compiled.
2. (configure:) (error:) cannot find header (file) <somename>.h OR (configure:) (error:) (header) (file) <somename>.h missing! OR <similar>
   • The configure script can't find a .h file required for compilation. This error is similar to the one above, as it requires you to install the -dev or -devel version of a certain package. However, it is usually less clear which package should be installed, as <somename> can be a very generic name. Try searching the web for <somename>.h to find out which package it belongs to, then try installing that package (including its -dev or -devel version, if available) using your distro's package manager.
3. (configure:) (error:) no acceptable cc found in <somedirectories>
   • Your gcc installation is either missing or the CC environment variable is not set. Check if the package gcc is installed, using your distro's package manager. If it isn't, install it. If it is installed, however, try using this command:

     [rechosen@localhost ~]$ export CC="/usr/bin/cc"

     If that worked, you can add the command to your /etc/profile (a file full of commands that are executed whenever any user logs in) so you won't have to set it again.
4. (configure:) (error:) C++ preprocessor "/lib/cpp" fails sanity check
   • Your g++ package is either missing or corrupted. Please use your distro's package manager (or any other method to find and install packages) to search for g++ and install the corresponding package. Note that quite some distro's do not call the package g++. Fedora, for example, uses the packagename gcc-c++ in its yum repositories. If you can't find g++, try searching for c++, cpp and/or gcc.
5. (configure:) (error:) C++ preprocessor "CC (-E)" fails sanity check
   • This is caused by a strange bug in certain versions of libtool that makes the configure script check for all compilers supported by libtool. The quickest solution is to install g++ (see the solution above this one).

Make errors

As make errors usually are too specific to make a nice list of generic ones, I will give you a list of general things to do that might help:

• If you're compiling using gcc 4 (use gcc -dumpversion to find out), try using an older compiler version. First, make sure that some older version is installed. This can usually be detected this way:

  [rechosen@localhost ~]$ ls /usr/bin/gcc*

  If that returns something like this:

  /usr/bin/gcc /usr/bin/gcc32

  Then you can use, in this case, the gcc32 command to compile with an older gcc version. If not, try using your distro's package manager to search for older versions of gcc (usually called something like compat-gcc or gcc-<versionnumber>). After installing, you should be able to detect the alternative gcc version using the ls command above. Tell the ./configure, make and make install sequence to use the older gcc version in a way like this:

  [rechosen@localhost ~]$ CC="/usr/bin/gcc32" ./configure[rechosen@localhost ~]$ CC="/usr/bin/gcc32" make[rechosen@localhost ~]$ CC="/usr/bin/gcc32" make install

  Note: in most cases, you can leave the /usr/bin away and just put the gcc executable name. However, some non-standard Makefiles might handle it in a different way. Therefore, including the full path is the safest option.Of course, replace the /usr/bin/gcc32 with the location of your alternative gcc command.
• Sometimes make errors are just caused by a plain bug. Try obtaining the latest development version of the software (using their cvs, svn or similar repository, or by downloading a nightly snapshot) and try compiling that one to see if they fixed the bug there.
• Make errors can also be caused by having wrong versions of certain libraries / programs. Especially very new and very old packages suffer from this problem. Have a look at the dependencies of the package (they are usually listed somewhere on the site of the software) and compare the version numbers there with the version numbers on your own computer (they can usually be found using the search function of your distro's package manager). If the version numbers on your system are way higher than the ones on the package's site, you are probably trying to compile a very old package. If you really need to compile it, try downgrading the dependencies. However, it usually is a better option to search for an other way to install the package or to look for an alternative. If the version numbers on your system are way lower than the ones on the package's site, you are either trying to compile a bleeding-edge package, or your distro is quite old, or both =). You could try updating the required libraries / programs or compiling an older version of the program. Also, have a look if a nice package made for your distro of the program exists. Installing such a package is usually easier than trying to deal with compilation errors.
• Another thing to try is searching the web for your specific error. If you don't find anything useful, try stripping away things like line numbers (they can change with versions), version numbers (you can replace them with an asterisk if they are contained in (file) names) and non-alphanumerical characters like quotes, as they influence the search engine's seeking. You can usually find a lot of information on mailing lists. Sometimes, a patch is provided that will fix the source code. Patches can be applied this way:

  [rechosen@localhost ~]$ patch -Np1 -i <patchfile>

  Note that you will need to be in the source directory to apply a patch.

Make install errors

These errors usually are quite easy to understand, but I'll document them anyway. There are two frequent causes that'll stop you from succesfully using make install:

• You do not have root permission. Try running make install using sudo or try becoming root using su. Sudo should be used this way:

  [rechosen@localhost ~]$ sudo make install

  It will ask for a password; this usually is either your own password or the system root password. You can use su to become root this way:

  [rechosen@localhost ~]$ su

  This command will also ask for a password, but it always is the system root password. After becoming root, just run make install as you'd do normally. And after that, don't forget to return to your normal user again if you used su. You can do this by pressing Ctrl + D or, if that didn't work, typing 'exit' or 'logout' and then pressing enter. However, this is only recommended if you became root using su. The sudo program only runs a command with root permissions, it doesn't log you in as root.
• The package you just compiled doesn't have the install target. In this case you will have to copy the compiled binaries to a bin directory yourself. If you do an ls in the source directory, executable files should appear light-green. These files could be copied to /usr/bin (or /usr/local/bin, if you prefer) in a way like this:

  [rechosen@localhost ~]$ cp <executablefile> /usr/bin

  However, this will make a mess of your /usr directory if you use it too much. You could also add the directory in which the executable is located to your PATH variable. Go to the directory, get the whole path of it this way:

  [rechosen@localhost ~]$ pwd

  Then paste the output of pwd into this command:

  [rechosen@localhost ~]$ export PATH="$PATH:<pwdoutput>"

  If you can just run the command now, it worked. Add the export command you ran to your /etc/profile, so you won't have to type it again.I agree that this isn't really a clean and easy way, but sometimes developers don't take the time to create a (proper) install target. We should not be angry with them: think of all the work they do to let us enjoy useful and/or funny programs =).

Other problems

Here is a list of some other general problems, with solutions:

• Everything went alright, but when I type the command I just installed bash says it cannot be found. This is usually caused by make install installing everything in /usr/local or in /opt/<packagename>. Have a look at the output of make install: where did it copy the files to? Try adding the bin directory of that location to your PATH variable (the following example assumes the package was installed to /usr/local):

  [rechosen@localhost ~]$ export PATH="$PATH:/usr/local/bin"

  You can just replace /usr/local/bin with the bin directory in which the executables of your package were installed. If this works, add the line to your /etc/profile so you won't have to type this again and again. By the way, you can control the place in which the package will be installed by specifying this option when running the configure script:

  [rechosen@localhost ~]$ ./configure --prefix=/usr

  Replace /usr if necessary with the directory in which you'd like to have the package installed. Note that you are only setting the prefix; the binaries will be installed in a subdirectory of the prefix, just like the libraries, header files and so on. When using the above prefix, for example, you will find the binaries in /usr/bin.
• I want to install a very old version of a package, but I can't find the source archive of it on the internet. You still have a small chance. Try searching for rpm's of the version you want and download the corresponding src rpm. Unpack it this way:

  [rechosen@localhost ~]$ rpm2cpio <rpmfile> | cpio -idv

  Now, use the source file that should have been extracted from the source rpm.

Final words

This tutorial is not finished yet. I plan to update it every now and then with solutions to requests from users. Therefore, I ask you to comment on it and say what you'd like to see documented in it. Remember that this tutorial is about generic troubleshooting. Don't ask me how to make a certain version of a certain program compile. Anyway, I hope this tutorial has been useful to you. Thanks for reading and good luck with that immersively complicated thing called compiling!