Linux Tutorial Blog

Your regular Linux tutorial source!

Troubleshooting ./configure, make and make install Tutorial

rechosen | 01 February, 2007 21:46

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!

Tutorials | Next | Previous | Comments (21) | Trackbacks (0)

Comments

omg

anonymous_from_lor | 02/02/2007, 22:00

> [rechosen@localhost ~]$ CC="/usr/bin/gcc32" ./configure
> [rechosen@localhost ~]$ CC="/usr/bin/gcc32" make
> [rechosen@localhost ~]$ CC="/usr/bin/gcc32" make install
First: it's not needed to put CC=.. before every command -just
use :

>export CC="/usr/bin/cc"
once,but this will work only in bash shell ,not in ksh|sh etc

Second:it's not needed to put full path to gcc in this variable just because if you don't have gcc/bin in your $PATH
and try to add full path to it in $CC -it will not work.

>ls /usr/bin/gcc*

this will list just names even if /usr/bin/gcc is a link and it's broken -you will see it but cannot use.

Actually there are much more interesting methods:

100% working everywhere but slow: find / -name gcc
fast but need locate util: updatedb & locate gcc

and of cause you'll need (most for all) add found gcc location to $PATH as:

export PATH=$PATH:/my/gcc/bin

or for ksh: setenv PATH "$PATH:/my/gcc/bin"

> sudo make install

this will work only if you already configured correctly /etc/sudoers -in almost all distros this is _not_ done (at least not for make command)

> cp /usr/bin
>./configure --prefix=/usr

NEVER _NEVER_ DO THINGS LIKE THESE!
(Or Linus Torvalds will come and kick your ass )
Because you'll get dll hell like in windoze in your system..

And for the last : there are not so many situations when you really need to compile package (if you gentoo user ,child or programmer) -try to use binary packages every time you can.

P.S.Yes ,i'm from linux.org.ru :)
P.P.S You always can ask lor's community in english -most of us know it.

Re: omg

Rechosen | 02/02/2007, 22:07

Thanks =). I'll have a look at it and update my tutorial where needed.

Re: omg

Rechosen | 02/02/2007, 22:50

Here are some comments on your suggestions:

>> [rechosen@localhost ~]$ CC="/usr/bin/gcc32" ./configure
>> [rechosen@localhost ~]$ CC="/usr/bin/gcc32" make
>> [rechosen@localhost ~]$ CC="/usr/bin/gcc32" make install
> First: it's not needed to put CC=.. before every command -just
> use :
>
>> export CC="/usr/bin/cc"
> once,but this will work only in bash shell ,not in ksh|sh etc
>
> Second:it's not needed to put full path to gcc in this variable just
> because if you don't have gcc/bin in your $PATH
> and try to add full path to it in $CC -it will not work.

I explicitly don't export this variable as that might spoil other things the user does in the same shell session (small chance, but you never know). Adding the full path to the gcc executable is done just for safety. I added a notice about that. Thanks for pointing me at it!

>> ls /usr/bin/gcc*
>
> this will list just names even if /usr/bin/gcc is a link and it's
> broken -you will see it but cannot use.
>
> Actually there are much more interesting methods:
>
> 100% working everywhere but slow: find / -name gcc
> fast but need locate util: updatedb & locate gcc
>
> and of cause you'll need (most for all) add found gcc location to
> $PATH as:
>
> export PATH=$PATH:/my/gcc/bin
>
> or for ksh: setenv PATH "$PATH:/my/gcc/bin"

Although I agree that using the ls command isn't a perfect way, it's probably harder to explain new linux users which one to pick when a find / updatedb returns not only executables, but also things like libaries, header files and who knows what else. It is kind of an agreement between user-friendliness and perfection. I don't like those kinds of agreements, but I think it's the best solution here =).

About setting the PATH variable: if I'm using the ls command like this, I don't think adding the path to $PATH would be necessary. The whole part about trying an older version of gcc should be temporary, as the user should try compiling with gcc 4 first.

>> sudo make install
>
> this will work only if you already configured correctly /etc/sudoers
> -in almost all distros this is _not_ done (at least not for make
> command)

Which is exactly why I also mention the way to use su. However, a default Ubuntu installation requires you to do everything with sudo, so I thought it'd be better to list sudo first, as su doesn't work on Ubuntu by default.

>> cp /usr/bin
>> ./configure --prefix=/usr
>
> NEVER _NEVER_ DO THINGS LIKE THESE!
> (Or Linus Torvalds will come and kick your ass )
> Because you'll get dll hell like in windoze in your system..

I don't quite understand what's wrong with the second one (I understand that the user could make a mess of it, but it's quite useful in many cases), but I agree on the first one. I adjusted that part to suggest an alternative.

> And for the last : there are not so many situations when you really
> need to compile package (if you gentoo user ,child or programmer)
> -try to use binary packages every time you can.

This tutorial is written just for those times when you do have to compile. Why would a user even try to grasp something like this when he/she can just use the distro's package manager?

> P.P.S You always can ask lor's community in english -most of us know
> it.

THe problem is that I don't know Russian, so I don't know where to ask it. I managed to post a comment by using Babelfish intensively, but I don't think I'll be able to do much more than that =).

Re: omg

anonymous_from_lor | 03/02/2007, 00:12

>Although I agree that using the ls command >isn't >a perfect way, it's probably harder to >explain new linux users which one to pick when >a find / updatedb returns not only >executables, >but also things like libaries, >header files and >who knows what else.

First of all: unix never had and as I think ( I'll pray for this) will never have file type setting depending of it's extension like in ms win. (.exe for executable and so on).Keep in mind that you can execute every file in unix by setting chmod +x on it.And this difference from
ms win must be explained to users before they will try to go into shell.

>About setting the PATH variable: if I'm using >the ls command like this, I don't think adding >the path to $PATH would be necessary. The >whole part about trying an older version of >gcc should be temporary, as the user should >try compiling with gcc 4 first.

Without adding $GCC_DIR/bin to $PATH compiler will never work correctly ,even 4th.

>Which is exactly why I also mention the way to >use su. However, a default Ubuntu installation >requires you to do everything with sudo, so I >thought it'd be better to list sudo first, as >su doesn't work on Ubuntu by default.

Actually I don't see any reasons for compilation under root - you almost always can do ./configure & make under user and even for make install root account is needed only if you haven't write permissions to destination dir. (/usr for example)

>I don't quite understand what's wrong with the >second one (I understand that the user could >make a mess of it, but it's quite useful in >many cases), but I agree on the first one. I >adjusted that part to suggest an alternative.

Because when you compiling something by hand and installing it to dir with other software ,especially if this dir is something like /usr /usr/local /usr/share and so on - you always have a chance to overwrite already existing library or binary used by another program.
This situation is similar to dll overwriting by 3rd party programs in windows known as 'dll hell'.

There are two ways not to get this - to make own dir, something like /opt/own and always install hand-compiled progs there (by setting --prefix=/opt/own for configure script)

..or use everytime and everywhere precompiled packages,which always have list of dependency libraries described in each package.

>This tutorial is written just for those times >when you do have to compile. Why would a user >even try to grasp something like this when >he/she can just use the distro's package >manager?

Sometimes young boys like to play with compiler and try to build everything by hand just because someone told them that this is 31337 and c00l and etc :)

>THe problem is that I don't know Russian, so I >don't know where to ask it. I managed to post >a comment by using Babelfish intensively, but >I don't think I'll be able to do much more >than that =).

Haha! Babelfish rules! We use it for talk with china and japan linux users :)

Re: omg

Rechosen | 03/02/2007, 20:27

> First of all: unix never had and as I think ( I'll pray for this) will
> never have file type setting depending of it's extension like in ms
> win. (.exe for executable and so on).Keep in mind that you can execute
> every file in unix by setting chmod +x on it.And this difference from
> ms win must be explained to users before they will try to go into
> shell.

I agree that this should be explained to new Linux users, but this is way beyond the scope of this tutorial. However, this seems to be a quite nice topic for a future tutorial =).

> Without adding $GCC_DIR/bin to $PATH compiler will never work
> correctly ,even 4th.

$GCC_DIR/bin should already be in the user's $PATH when he/she reaches that part of the tutorial. I think it would be a bit of an overkill to explain it at that place. If the user managed to get a make error, the configure script must have found (g)cc in one of the directories in the $PATH variable. If the user is trying to compile using just a Makefile without a configure script, that doesn't take away the fact that about every mainstream distro places all gcc-related commands in /usr/bin. I still think the current way it is told in the tutorial is the best agreement between user-friendliness (keeping explanations short also is a part of user-friendliness) and perfection. It's quite a complicate issue =).

> Actually I don't see any reasons for compilation under root - you
> almost always can do ./configure & make under user and even for make
> install root account is needed only if you haven't write permissions
> to destination dir. (/usr for example)

I can't recall having told the user to compile as root. That part is about running make install, not ./configure or make. However, this made me realize that I should tell the user to logout again after using su. I just added that.

> Because when you compiling something by hand and installing it to
> dir with other software ,especially if this dir is something like
> /usr /usr/local /usr/share and so on - you always have a chance to
> overwrite already existing library or binary used by another
> program.
> This situation is similar to dll overwriting by 3rd party programs
> in windows known as 'dll hell'.
>
> There are two ways not to get this - to make own dir, something like
> /opt/own and always install hand-compiled progs there (by setting
> --prefix=/opt/own for configure script)
>
> ..or use everytime and everywhere precompiled packages,which always
> have list of dependency libraries described in each package.

I think this also is beyond the scope of this tutorial. I know that this can happen, indeed. Compiling can be risky, but that's not what the tutorial tells about. The tutorial tells how to fix common errors that users might stumble upon when compiling.

> Sometimes young boys like to play with compiler and try to build
> everything by hand just because someone told them that this is 31337
> and c00l and etc :)

Like me building LFS when I was 14? =)

> Haha! Babelfish rules! We use it for talk with china and japan linux
> users :)

That must result in some quite strange conversations =).

Re: omg

anonymous_from_lor | 03/02/2007, 21:22

>I agree that this should be explained to new Linux users, but >this is way beyond the scope of this tutorial. However, this >seems to be a quite nice topic for a future tutorial =).

After watching this sales-hit book

http://www.amazon.com/How-Shit-Woods-Environmentally-Approach/dp/0898156270

I cannot belive any more in non-stupid users :)

>still think the current way it is told in the tutorial is the >best agreement between user-friendliness (keeping >explanations short also is a part of user-friendliness) and >perfection. It's quite a complicate issue =).

That depends only of your ability to help to a lot of newbie (or dumb) users when they will use your tutorial - if you can (or want) to respond everytime when someone cannot find compiler or using non-gcc compiler or something else..

IMHO short answer "see http://../make-install-tutorial#ch5.6"
will be better "agreement between user-friendliness and perfection" than a lot of repeated answers in thread :)

>I think this also is beyond the scope of this tutorial. I >know that this can happen, indeed.
> Compiling can be risky, >but that's not what the tutorial >tells about.

Actually ,right now your tutorial (at least in first edition) is a best way to move system to hell :) Especially if someone will try to compile and install something like glibc,gettext,libiconv,gtk and so on.

If you dont want to write detailed describtion about these risks in your tutorial -that's ok ,but please add at least
big red string: THIS ACTION CAN DAMAGE YOUR SYSTEM! or something like this at the end of tutorial.

(That's because someone had translated your tutorial to russian and I had already more than ten questions about it from dumb users in icq.. )

>The tutorial >tells how to fix common errors that users might >stumble upon >when compiling.

I'll adwise then to add section about common linking problems
(LD_LIBRARY_PATH,ld.conf and so on),because this is most happened kind of problems during compilation.

And also will be good to add info about 64bit software compilation issues -a lot of users have x86_64 hardware now.

>Like me building LFS when I was 14? =)
OMG! old sch00l!

Re: omg

Rechosen | 05/02/2007, 14:18

> After watching this sales-hit book
>
> http://www.amazon.com/How-Shit-Woods-Environmentally-Approach/dp/0898156270
>
> I cannot belive any more in non-stupid users :)

Alright, I'll place a warning above the tutorial =).

> That depends only of your ability to help to a lot of newbie (or
> dumb) users when they will use your tutorial - if you can (or want)
> to respond everytime when someone cannot find compiler or using
> non-gcc compiler or something else..
>
> IMHO short answer "see http://../make-install-tutorial#ch5.6"
> will be better "agreement between user-friendliness and perfection"
> than a lot of repeated answers in thread :)

Of course, that tutorial would actually have to exist. My time to dedicate to this site is not infinite =). However, I might write a tutorial especially on that.

> I'll adwise then to add section about common linking problems
> (LD_LIBRARY_PATH,ld.conf and so on),because this is most happened
> kind of problems during compilation.
>
> And also will be good to add info about 64bit software compilation
> issues -a lot of users have x86_64 hardware now.

Good idea! And another frequent issue is the PKG_CONFIG_PATH. I hope to add these to the tutorial, soon.

Re: omg

alex | 06/02/2007, 20:14

>Good idea! And another frequent issue is the PKG_CONFIG_PATH. I >hope to add these to the tutorial, soon.

Basically it's not a good idea to set this variable. Error message during ./configure about it almost everytime means that you didn't add directory with pkg-config util to $PATH.And this util searches installed packages into dirs defined in $PATH variable,so you need to set PKG_CONFIG_PATH only if you compiling pkg-config by hands and store it in non-$PATH dir.

P.S If you'll intersting -I can post there some info about fixing errors during compilation and you will mix it into tutorial?

Re: omg

Rechosen | 06/02/2007, 20:37

> Basically it's not a good idea to set this variable. Error message
> during ./configure about it almost everytime means that you didn't add
> directory with pkg-config util to $PATH.And this util searches
> installed packages into dirs defined in $PATH variable,so you need to
> set PKG_CONFIG_PATH only if you compiling pkg-config by hands and
> store it in non-$PATH dir.

I personally encountered pkgconfig errors that were caused by the pkgconfig dir not being added to PKG_CONFIG_PATH a lot. But anyway, I'll do some research on that one before posting anything.

> P.S If you'll intersting -I can post there some info about fixing
> errors during compilation and you will mix it into tutorial?

I am interested, but please try to write it in well-formed English. I am determined to maintain the quality of this site at that point: the tutorials should contain as few spelling / grammar mistakes as possible. If you don't think you could do that, please just try to explain the info you have to me, and I'll see what I can do with it. Thanks in advance =).

Re: Troubleshooting ./configure, make and make install Tutorial

alex | 06/02/2007, 22:11

>I am interested, but please try to write it in well-formed >English.
That's why I'm asking you to compile this posts into tutorial :) That's because my ${NATIVE_LANGUAGE} is C :)

So let's go!

1)Some basic info. (this is boring but needed)

Most of all programs in unix world were written in C/C++ ,so fixing of common errors during compilation requires at least basic knowelenges about this languages and related stuff, such as linking and compilation methods. Certainly, the world of compilators is too big to fit into this small block ,so i'll assuming that you're using GCC compiler by default ,not intel or something else.

Ok,that's all.Backing to business.

2)Compilation process.

To compile some code in C into binary without any make-like utilities use:

gcc code.c -o code

If you have more than one .c file:

gcc -o main main.c libs.c

main.c there and code.c in first example must contain:

int main(int argc, char *argv[])

function!

To compile some C++ code :

g++ -c code.cpp -o code.o

2)Libraries (yes, it's place for love :))

You maybe often had seen -lnsl, -liconv ,-lpthread stuff after
gcc or g++ string during compilation and don't know what it means? All of this are linked libraries.
Principe is simple: -l.
So for example to link libiconv.so you'll need to add -liconv param.
But you must know that linking libraries is hierarchical!

For example when some code using shared library ,this library must be included _before_ including that code:

gcc -o main main.c -liconv lib_use_iconv.c

But this not nessesary if you have only one source file.

2.1 (LD_LIBRARY_PATH & ld.conf hell)

Of cause before link any library to code you must verify that
this library is searchable in $PATH (for example if exist /usr/bin in your $PATH -you can link all libraries laying in /usr/lib )
But sometimes you need to overwrite or add some location of libraries -and $LD_LIBRARY_PATH is going to scene -linker will
search linked library in dirs listed in this variable.

But if you used it until compilation -you also must understand that running compiled program without setting LD_LIBRARY_PATH to same value as during compilation (or adding every $dir/../bin in LD_LIBRARY_PATH to $PATH or just adding $dir to ld.conf ) will gave you .core dump file.(program will not work)

next (some info about ld.conf)

alex | 06/02/2007, 22:23

As I always say - most simple solution will never be the best :)
In other words -using LD_LIBRARY_PATH variable is last and worst
solution to get your program compiled.
Standard (and best ) way is using ld.conf (or often ld.so.conf).
This is config file for gnu linker ,it's located (most often) in /etc/ld.conf or /etc/ld.so.conf and contains list of directories
in whitch libraries are searching during linking.

world of make

alex | 06/02/2007, 22:54

The world where we all living is big and strange ,maybe that's why there are so many utilities designed to automate compilation
procedures in unix :)

Most popular util of cause is gnu make.In every linux distribution it's called just 'make', in Solaris and *bsd for example -it's gmake.Less popular are imake and cmake -oriented mostly in crossplatform compilation.

So everytime when you see Makefile into root of sources -you must use gnu make (or sometimes native make if you working in Solaris).If you see Imakefile -use imake.

But besides of all this wonderful stuff there are utils designed for run _before_ make-like utils.

First of all it's qmake - utility for link qt libraries.

For example to compile any graphical program whitch using qt -you must first run

qmake -o Makefile code.pro

to generate Makefile.And only after that - make & make install.
But before using qmake you'll need (in most distros) to set
$QTMAKESPECS variable whitch must point to $QTDIR/mkspecs/linux-g++ (again that's not for all, for solaris it will be ..solaris-g++, for freebsd : ..freebsd-g++).
And also you almost everytime must set QTDIR variable points to _devel_ version of qt library.

some words about java

alex | 06/02/2007, 23:36

Today java is one of most popular languages in the world.But it doesn't means that i'll stop hating java and stop using C.
This just means that a lot of users have troubles with compilation of java projects.

There are two main versions of java: JDK (Java Developer Kit) and JRE (Java Runtime Enviroment).This concerns to Sun's java implementations only (As far as I know IBM has only own JDK implementation ,not JRE and Kaffe -opensource implementation also just jdk).Main difference between jdk and jre is precence of compiler in first.So every time when you need to compile java project you'll need installed jdk.

Also there are a gnu util called jikes -java to binary code compiler.

[boring]:
You must know that java compiler translates java code into pseudocode ,not binary executable like ELF or EXE or someting.That's why java is fully crossplatform system -you can compile code on Solaris and it will run on Windows or Linux.

But jikes compiles java code directly into executable binary -java loosing crossplatform abilities but speed of execution is increasing.
[warning]
Before using jikes -you must know about it's limitations - for example it _will not_ compile any j2ee code:application servers like jboss and e.t.c..And as I know it only implements
1.4 version of j2se.

So compilation of java code:

javac -cp . Code.java

..and running:

java -cp . Code

-cp parameter there is a CLASSPATH whitch contains list of directories with java libraries (.jar files) or java sources
(.java files) or java compiled code (.class files)

Also you must know about building utility called ant (similar as make-like utils for c|c++).
If you'll see build.xml file into root of sources -just type

ant

there.
(Of cause you must install ant before using it :))

Ok, that's all for today (haha ,actually -tonight) -maybe I'll add something more later.

P.S. And plz fix my ugly english everywhere you can - I'm still learning it :)

Thanks alex!

Rechosen | 07/02/2007, 09:27

The things you wrote are pretty useful. However, I think they are outside the scope of this tutorial, as this tutorial is about fixing errors when compiling an automake-generated source archive, and your tutorial is more about how to compile (although it does contain a part about error-fixing, I'll include that in this tutorial). I think I'll create a new tutorial with it (something like "Tutorial: More about compiling") and also add build systems like scons. Of course, I would give you credit because the tutorial would be based on your text. Is that ok with you?

That was only intro :)

alex | 07/02/2007, 14:35

I know that posted info is outside of your tutorial topic but this was only intro -today everning i'll post detailed info about fixing errors during compilation qt programs (krusader will be best example IMHO),java program (jedit ) and c/cpp (wine ,qemu)

Re: Thanks alex!

alex | 07/02/2007, 14:37

>something like "Tutorial: More about compiling") and also add >build systems like scons. Of course, I would give you credit >because the tutorial would be based on your text. Is that ok with >you?

Yes ,it will be cool :)

1)fixing errors during compilation of qt-based programs

alex | 07/02/2007, 23:15

One of the most recenlty used qt-based programs is Krusader (http://krusader.sourceforge.net/) ,so it will be good idea to use this program as example.

I skipping there download & unpacking stages -let's assume that you already downloaded source code and unpacked it into some directory.
First we will try to do simple:

./configure --prefix=/opt/own

"--prefix=/opt/own" means that execution of 'make install' will install program into /opt/own directory.

[boring]
You also must know that programs in unix world most everytime are installing into multiple directories at once:

all executable binaries are installing into $prefix/bin dir,
all configuration files - into $prefix/etc
all libraries - into $prefix/lib
all resources (pics,sounds,icons) - into $prefix/share
all headers -into $prefix/include
all mans -into $prefix/man

So to make krusader work correctly after install into $prefix dir we'll need to do at least two things: add $prefix/bin to $PATH variable and add $prefix/lib to $LD_LIBRARY_PATH or to ld.conf|ld.so.conf
[/boring]

But in most popular distros we'll get error during ./configure execution:

"checking for Qt... configure: error: Qt (>= Qt x.x ) (headers and libraries) not found.Please check your installation!"

This means that you haven't qt headers in any of $DIR/include dir listed in $PATH.

Let's locate it:

alex@desk.home.local: locate libqt*.so
/usr/lib/qt3/lib/libqt-mt.so.3.3.6
/usr/lib/qt3/lib/libqt-mt.so.3
/usr/lib/qt3/lib/libqt-mt.so.3.3
/usr/lib/qt3/lib/libqtextra.so.1
/usr/lib/qt3/lib/libqtextra.so.1.0
/usr/lib/qt3/lib/libqtextra.so.1.0.4
..

This means that you have installed qt libraries but maybe _not_ headers.To check if you have also installed qt headers
(located in qt-devel package):

alex@desk.home.local: locate qt.h
/usr/lib/qt3/include/qt.h

This means I have installed qt headers in dir (because every devel qt package contains this file):
/usr/lib/qt3/include.

Let's add this dir into ld.so.conf:

echo /usr/lib/qt3/lib >>/etc/ld.so.conf

[boring]
Linker searching headers (.h files) in $DIR/../include dirs, listed in $PATH or $LD_LIBRARY_PATH variables or in /etc/ld.so.conf file.

Now ./configure script must successfully find our qt libraries & headers.

But we have one more error:

checking for KDE... configure: error:
in the prefix,you've chosen,are no KDE headers installed.
This will fail.So, check this please and use another prefix!

[!] This is not absolutely correct - script didn't find kde headers that's true but these headers have no any reason to be in $prefix - because they are always somewhere in /usr , /usr/local/ and so on (depends of used distro)

To fix this error -just install libkde-devel package.

Next error happens afaik only in cvs|beta versions of crusader and only in crusader (but google said that a lot of people have troubles with this):

config.status: error: cannot find input file: doc/it/Makefile.in

To fix it you must manually edit configure file in root of krusader's sources and comment out line 32840:

ac_config_files="$ac_config_files doc/it/Makefile"

by adding '#' symbol as first letter of this string.

Ok.Now configure script finished correctly without any errors.
Running make & make install were also without any errors on my system ,but you may get some if haven't installed automake, libpng , e.t.c libs.

linux troubleshooting

pranjal | 23/02/2008, 11:57

brifly explain about the kernel paining with example.

What about the linker

dargaud | 21/04/2008, 11:12

Thanks for the tutorial, I can cross-compile most apps now. But what if there's no configure scritp, just one big makefile. With CC=... I can tell it to use the proper compiler, but then the linking stage fails because it then uses /bin/ld instead of .../powerpc-linux-ld, and I can't even change a line in the make file as ld is not called explicitely (it part of a gcc call).

Excellent Tutorial!

dannysfather | 12/11/2008, 07:13

After years of stumbling about, attempting to install apps, this single page quickly explained what I needed to know, especially the first 2 errors.

Thank you very much Rechosen!

I didn't know "make" would take so long.
I would have "xkilled" the terminal, except I found another webpage which mentioned long MAKE times as average.

Thankyou Thankyou Thankyou!

Add comment

(optional, will not be published)
(optional)
1 2  Next»
© 2007-2008 by Rechosen. | Valid XHTML | Valid CSS | Powered by Lifetype | DMOZ tag directory
-
Revenue generated from this site is invested into my study.

<><