- .dll is the extension for a Windows dynamic library. DLL Hell exists and even has a Wikipedia entry.
- .lib is the extension for both a DLL wrapper, as it is used for static libraries. A DLL wrapper or "import" LIB file, which is used to link against. For each function the DLL exports, the LIB file contains a stub which will load and call into the DLL. You only need these .lib files when linking, but not when deploying.
- If on Windows a DLL is missing, you will get hit during run time, as it can not find the DLL module to load. On Unix, the application will not start up. This has pro's an cons. Pro: if you do not want to use a particular feature of the application, which requires an expensive 3rd party library, you can still run the application. The con: if your application was doing a lot of work and then aborts, you will slap the machine a couple of times.
- Convention: Files ending with z.lib or zd.lib are the static libraries. (d for debug)
- C Run Time (CRT) libraries are development environment dependent. If your program links against both, you have to be very very careful. Since memory management are (slightly) different between CRTs, linking against malloc()/free() from different CRTs can corrupt your heap. The bug will unfortunately show up in weird and unrelated ways. The take away is avoid linking against two different CRTs. But if you have to, make sure you keep your program modules separate. For reference:
- msvcrt.dll is used by VC6.0
- msvcr70.dll for VS .NET
- msvcr71.dll for VS .NET 2003
- msvcr80.dll for VS 2005
- with "d" added to the name for debug CRTs
- Static libraries (archives) are created and updated by the ar (archive) utility. Convention dictates that static libraries have a ".a" extension on their filename.
- Dynamically linked libraries are created by the link editor, ld. The conventional file extension for a dynamic library is ".so" (shared object).
- You tell the compiler to link with, libpthread.so, by giving the option -lthread.
- The compiler finds libraries as specificied by LD_LIBRARY_PATH or using the compiler option -Lpathname.
- nm utility to the rescue when you run into Undefined Symbols
- The order of statically linked libraries on the compiler command line is significant: (i..e they should be listed after your own code). Although I believe gcc can be instructed to make a few passes through the static library arguments to make sure undefined symbols, defined in previously stated static libraries are picked up.
- Knowing which library files to link against is sometimes a mystery. Take a look at the #includes and guess the library name. Often the man pages might mention something as well.
Technorati: Linking C Compiler Peter Van Der Linden Windows Unix