I created a cpp project, which used a lib file named:
usr/bin/ld: cannot find -lblpapi3_64
ld does not know about where your project libs are located. You have to place it into ld's known directories or specify the full path of your library by
-L parameter to the linker.
To be able to build your program you need to have your library in
/bin/ld search paths and your colleague too. Why? See detailed answer.
At first we should understand what tools do what:
Libraries, in fact, are just an object files which are placed into a single archive by using
ar tool with a single symbols table which is created by
Compiler, when compiling object files, does not resolve
symbols. These symbols will be replaced to addresses by linkers. Why
linkers? Because here are two linkers:
ld. It does 2 jobs:
a) for static libs, this linker changes external symbols in the object files to the addresses of the real entities. For example, if we use C++ name mangling linker will change
b) for dynamic libs it only checks if the symbols can be resolved at all but does not replace the symbols by address. If symbols can't be resolved (so they are not implemented in the shared library you are linking to) - it throws
undefined reference to error and break up building process because you try to use them but linker can't find such symbol in it's object files which it is processing at this time. Otherwise, this linker adds
.interp section to the
ELF executable which has:
i. Request for an
interpreter (dynamic linker) to be called before executing.
ii. A list of libraries which
interpreter will be looking for before executing.
Static linker works at build time.
ld-linux. It finds and loads all the shared libraries needed by a program (if they were not loaded before), resolves the symbols by replacing them to real addresses right before start of the program, prepares the program to run, and then runs it. It works after build and before running the program. Less speaking, dynamic linking means resolving symbols in your executable before each program start.
Actually, when you run an
ELF executable with
.interp section (it needs to load some shared libraries) the OS (Linux) runs an interpreter at first but not actually your program. Otherwise you have an undefined behavior - you have symbols in your program but they are not defined by addresses which usually means that the program will be unable to work properly.
You may also run dynamic linker by yourself but it is unnecessary (binary is
/lib/ld-linux.so.2 for 32-bit architecture elf and
/lib64/ld-linux-x86-64.so.2 for 64-bit architecture elf).
Why does static linker claim that
usr/bin/ld: cannot find -lblpapi3_64 in your case? Because it tries to find all the libraries in it's known paths. Why does it search the library if it will be loaded during runtime? Because it needs to specify which library dynamic linker should link to during runtime and to add the
.interp section. Actually, the
.interp section exists in almost each c/c++ elf because the
libstdc++ libraries are both shared and compiler by default links dynamically to them but you may do that link to them statically also but this will enlarge the total executable size. So, if the shared library can't be found your symbols will remain unresolved and you will be UNABLE to run your application, thus it can't produce an executable. You may get the list of these dirs by:
ld --verbose's output.
Some of these methods are explained here.
Dynamic linker tries to find all the libraries by using:
DT_RPATHdynamic section of ELF file.
DT_RUNPATHsection of the executable.
/etc/ld.so.cache- own cache file which contains a compiled list of candidate libraries previously found in the augmented library path.
After all of that:
ld-linux) so it needs to be in it's paths (see above) or in system linker paths. In most of linux program distributions, for example, games from steam, there is a shell-script which sets the
LD_LIBRARY_PATHvariable which points to all shared libraries needed by the game.