|
||||||||||||||||
|
Linking libraries
|
|
|
Windows, like most operating systems, can link library routines into your application in two fundamentally different ways. Static linking means that a given external reference (e.g., a function name) is resolved at link time by finding the requested object in a static library and inserting the object code directly into your application. In other words, the necessary machine language instructions are copied from the library directly into your executable file, where they become part of your application. Dynamic linking means that the object code is not incorporated into your application at link time; instead, your executable is equipped with instructions on how to find that routine in a specific dynamic-link library, i.e., a file having a .dll extension. At run time, this routine will be loaded from the DLL only when needed by the program that calls it. As a result, your executable is smaller in size, but it now depends on the presence of a particular DLL to run correctly. Please note that linking against a file with a .lib extension does not guarantee that your routines are statically linked! Some .lib files are import libraries that merely contain redirections to a DLL instead of object code. The related DLL will generally have the same name as the .lib file. A good example of this at CTC is mpipro.lib, which is the import library for mpipro.dll. Accordingly, MPI codes at CTC will run only on machines where mpipro.dll is both present and in the PATH. Fortunately, all CTC's parallel compute nodes are equipped with this DLL, and your path is automatically reset for you. All Windows applications depend on DLLs to an extent because certain DLLs are used to provide the interface to the operating system. It is common for Windows applications to depend on kernel32.dll and ntdll.dll, for instance. If you want to see the exact DLLs upon which your application depends, you can use the Dependency Checker on a machine where Visual Studio is installed: |
|
![]() |
||