Ask Ubuntu is a question and answer site for Ubuntu users and developers. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I'm trying to understand how libraries work. Here are some questions I have about it:

  1. I downloaded a tarball and extracted it. When I do "./configure", it searches in pre-defined directories from what I understand for certain library files.

    What does it do then? It creates a makefile, and the makefile contains the paths to these libraries?

    Then I do "make", it compiles the source code and hard-codes the locations of the libraries? Am I correct?

    I do not really understand if libraries are files with pre-defined paths or the OS somehow gives access to the libraries through system calls.

  2. I complied something on my computer than moved it to a remote server, the executable needs MySQL libraries to work, the server has MySQL but for some reason when executing the file it tells me "can't find". Is there a solution for this? Is there a way to know where is tries to locate this file or give it another path?

    I can't compile it on the server since it has no compiler and I don't have root access to install packages.

  3. Last question is if in the sequence "./configure","make","make install" the "make install" command is the only one that actually puts files outside the directory in which these files reside?

    If for example the software will be installed in /usr/local/ is the "make install" command the only one that will require "sudo" before it?

    Let me see if I got it correctly: "./configure" creates the Makefile according to the location of various files on your system. "make" compiles the source code according to this makefile. And "make install" moves the files to their appropriate location.

Thank you to those who had the patience to read my questions.

share|improve this question
one more thing, the "./configure" command, does it overwrite the Makefile every time? if for example I run it and there's an error, can it cause any damage or once I fix the error it will just overwrite the Makefile and everything's OK? – fiftyeight Jul 1 '11 at 1:15
up vote 3 down vote accepted

configure generates a Makefile and often other files, such as config.cache. The contents of these files is based on the options you pass to configure and on observing your system. For example, many programs have optional components, and configure looks for the dependencies of each component and generates a makefile that only builds the components for which you have all the dependencies.

If you run configure and then change your system configuration, you should do make distclean first (if the program follows the usual conventions), to remove the makefile and configure's cache. Running configure again typically works when you want to pass it different arguments, but not when it's cached observations about your system.

Regarding libraries, the configure stage looks at what you have from a source compatibility point of view. If libfoo2 is source-compatible with libfoo3 but not with libfoo1, and you have libfoo2, then the resulting makefile will work build a binary linked against libfoo2 or a binary linked against libfoo3 but not a binary linked against libfoo1 (compilation would fail due to the source-level incompatibility).

When the executable is compiled and linked, the version requirement becomes more precise: the resulting executable needs a binary-compatible library (same ABI, not just same API).

Executables don't hard-code full paths to libraries; they hard-code names of libraries (-l argument to the linker) and sometimes a runtime library search path (-rpath) that comes in addition to the default search path of the target system. Finding the libraries at run time is the job of the dynamic linker.

I recommend playing a little with ldd and strace. ldd shows the libraries required by an executable and where the system would find them. strace shows all the system calls that happen when a program is loaded; the first few come from the dynamic linker that loads the required libraries. Here are a few experiments whose results you should try to understand.

ldd /bin/true
strace /bin/true
perl -pe 's/libc\.so/libc.zz/' </bin/true >broken
chmod +x broken
ldd ./broken
strace ./broken
ln -s /lib/ libc.zz.6
LD_LIBRARY_PATH=. strace ./broken

Summarizing the answers to your specific questions:

  1. configure hard-codes source compatibility issues. The make step hard-codes binary compatibility issues. Library locations are determined at run time.
  2. If only the location of the library has changed, the dynamic linker will typically find it (if you have a library installed in a non-standard location, pass the LD_LIBRARY_PATH environment variable). If you have only a different version of the library, then it's not the same library; you need to either get a library with the ABI version that your program is compiled against, or compile your program against the ABI version for which you have the library installed.
  3. configure determines the build configuration from what you have on your system and the arguments you pass. make builds the executable and other bits. make install copies the bits into place; only this stage might require elevated permissions (if you don't already have permission to write to the target directory, which you would e.g. if you were installing into your home directory).
  4. configure overwrites the makefile, but just re-running configure doesn't start from scratch because it keeps a cache.
share|improve this answer
THANX A LOT for the detailed answer :) – fiftyeight Jul 4 '11 at 22:52

I believe that when you ./configure on one computer, it derives a makefile specific for that one computer, then when you transfer the compiled program, the library is not where the makefile (or the executable) knew it was, so it throw out an error. As you can see that when you configure, not every library it checks for is required. So it must make a different makefile depending on your system. Another example of this is when you have a different architecture it requires different libraries, and so on.

And yes you have the order correct. 'make' is the safe command, only working in the current directory, sudo is basically required for 'make install'. It's bad to not have root privilages when installing software.

share|improve this answer
Do you know if the paths of the libraries are hard-coded into the exectuable? or is there something I can do, some command to make the file load a different library? – fiftyeight Jul 1 '11 at 18:11

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.