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.so.6 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.