Linker, Libraries & Directories Information

I've finished both my C++ 1/2 classes and we did not cover anything on Linking to libraries or adding additional libraries to C++ code.

I've been having a hay-day trying to figure this out; I've been unable to find basic information linking to objects. Initially I thought the problem was the IDE (Netbeans; and Code::Blocks). However I've been unable to get wxWidgets and GTKMM setup.

Can someone point me in the right direction on the terminology and basic information about #including files and linking files in a Cpp application? Basically I want/need to know everything in regards to this process. The difference between .dll, .lib, .o, .lib.a, .dll.a. The difference between a .h and a "library" (.dll, .lib correct?)

I understa开发者_Go百科nd I need to read the compiler documentation I am using; however all compilers (that I know of) use linker and headers; I need to learn this information.

Please point me in the right direction! :]

So far on my quest I've found out:

• Linker links libraries already compiled to your project.
• .a files are static libraries (.lib in windows)
• .dll in windows is a shared library (.so in *nix)

On a Unix-like system, you usually find libraries in /usr/lib. The .a extension indicates that you are dealing with an archive file created for example with ar. They are created from object files with the extension .o. The linker can then resolve references at compile time. They are called static libraries, because the machine code from the object file is copied into the final executable.

If you for example consider the math library, you will find the library itself at /usr/bin/libm.a and the corresponding header file in your include directory (e.g.:/usr/include/math.h). You have to include the header math.h for the compiler and for the linker specify the library libm.a to resolve the references, which where left by the compiler.

Shared libraries use the extension .so. They are useful if you want to have a small executable file. Here, the references are not resolved by the linker, but when the executable is started, the loader will look for the library dynamically and load them according to the unresolved references into memory.

.dll are dynamically linked libraries for Microsoft Windows and I am not very familiar with them, but I assume, that the steps involved are similar.