Linker static links and dynamic links

First, the preface

Recently in the project need to use a company's can card, and then to the official website to download the officially provided library files, downloaded 3 files. h,. Lib,. Dll,ok, now the protagonist appears,. lib and. dll.

In fact, the general library files are included in the three files, but their contact is still relatively small, so far with three of the company's equipment, a German, a Japanese company, there is a can card of this House, The top two foreign large enterprises are provided. h and. Lib, there is no. dll, that is to say, in two development, you just need to write your own. h,. The CPP file is compiled with the official. lib file on the line that can be run, although also aware of the existence of DLL, is not a dynamic link library, and, like. Lib, are other people's written implementation code, but at that time did not really delve into it. The difference between Lib and. dll, until the company's can card was encountered, and is to use the previous approach is only to refer to the. lib file, the program compiles no problem, but can not be implemented, of course, this knowledge is a small problem, that is, the absence of the corresponding. dll file, add in can be executed (why compile no problem, and run a problem. There are answers later). But as a programmer, need to have a problem, know it, we must know why (I am the opposite is the case, perhaps some programmers are very opposed to this view, because their point of view is as long as the use of the line), and then on a variety of Baidu, turn the book, the following personal insights.

Second, link

In an in-depth understanding of computer systems, P448, a link is defined as the process of gathering and combining various pieces of code and data into a single file that can be loaded (or copied) into memory and executed. This is the definition, then in practice. The link process is to combine. obj (Windows) and. Lib (which is also a set of. obj, a set of relocatable target files) to be merged to generate an executable target file. First of all, the links are divided into static links and dynamic links, static links are completed by the static linker, and dynamic link is completed by the dynamic linker.

1. Static link

static links are divided into two steps of symbolic parsing and relocation, in which symbolic parsing is mainly associated with a symbol definition in a module, which is a single relocatable target file, in the module's symbol table. In Windows is an. obj file, and relocation defines each symbol in the symbol table of multiple modules with a memory address unique association, which completes the symbolic reference to the symbol definition, and then to the full mapping of the memory, because a symbol is referenced, Not just to get or change the value of his memory.

(1) Symbolic analysis

In a relocatable file (module), there are three linker symbols: The global symbol can be referenced by other modules, the global symbols of other modules, and local symbols . Note that the local symbol here is the global symbol that is positioned outside of all functions in the current module and has a static attribute, not a local variable within the function, and the linker does not care about local variables within the function, which is managed by the Run-time stack, as follows:

/*********************m.cpp*****************************/

extern int E;

int A;

static int b;

void Fun (int c)

{

int d = c;

return D;

}

In module m shown above, symbol A is a global symbol that can be referenced by other modules. Symbol e is a global symbol referencing other modules, while symbol B is the local symbol for target m, it can only be referenced within module M, other modules are not visible, and symbols C and D are local process variables of module m, managed by the runtime stack.

Because there are different symbol types in the linker context (3 of these), the linker's symbolic resolution objects are broadly divided into two cases: referencing local symbols and referencing global symbols.

A. Reference local symbols. This process is very simple, direct control of the relationship on the line

B. Reference global symbols. This process is a bit complicated, just imagine, in two modules at the same time two names the same global symbol, the linker how to deal with it. Of course is to define a set of own rules to avoid some trouble, these rules are based on strong sign and weak symbol definition, strong symbol refers to the function and defined global variables, weak symbol refers to undefined global variables, this set of rules is: if there are more than one strong symbol, the error If there is a strong symbol and a number of weak symbols, select the strong symbol, if there are more than one weak symbol, randomly select a weak symbol. As follows, the first case of the example error

/fun1.cpp*/

int main ()

{

return 0;

}

/fun2.cpp*/

int main ()

{

return 0;

}

The second case does not complain, but the result is different from what you expected

/m1.cpp*/

int x=123;

void Fun ();

int main ()

{

Fun ();

cout<<x<<endl;

return 0;

}

/fun.cpp*/

int x;

void Fun ()

{

x=234;

}

If you run the program, the x=234 is output because the strong symbol x, defined in the M module, is linked in the module FUN.CPP.

(2) reposition

Just to understand that, in the link process, when all the symbol references are associated with the symbol location, we still don't know what to reference the symbol because the content is stored in memory, which requires relocation to complete, and relocation includes the relocation section and the symbol definition, and the symbol reference in the relocation section two steps. After the relocation is complete, the memory value referenced by the reference is known.

(3) link with Static library

The static library is the first mentioned. lib file, which is a collection of target modules, it contains a set of target modules (relocatable target file), when we deliver our CPP file and Lib library file chain into the executable file, only the static library is referenced by the application module copy out, the symbolic parsing process is the same as above. For example, we have written a m.cpp file, we need to use some of the functions provided by others, such as Fun1.cpp,fun2.cpp, in the. lib library file, it should be a relocatable module with FUN1, and fun2 modules, assuming the name Fun1.obj, Fun2.obj, and we write the M module by compiler and assembler become m.obj target file, the link process is the merging m.obj, Fun1.obj, The process of fun2.obj, that is, not copying the entire. lib file, but copying only the fun1 and fun2 two files, which is also a way to reduce memory resource consumption, how does the linker implement this process.

It is done through 3 sets: E, U, D. Where set E represents a set of relocatable target files maintained by the linker, which is just beginning to be empty, the linker merges the target file in the collection, generates the executable target file, and the set U is represented as a parsed symbolic reference. In the. cpp file that we have written, the symbol that has not yet been defined, is empty at first, and the set D represents the defined collection of symbols, which is initially empty. The specific process can refer to "deep understanding of computer systems" (the original book second edition) p460 content.

In summary, linking to a static library (that is, referencing a static library) requires understanding two concepts: (1) A static library is a set of relocatable target file collections (. obj files under Windows); (2) during a link, the application copies only the object files referenced in its own source program, not the entire. lib library file.

(4) dynamic Link shared library

The static library has its own advantages, there are drawbacks, the disadvantage is that the need to regularly maintain updates, and then reference the static library file to the application of the library file to be linked to the correct operation, the main problem is that with the static library links need to directly copy the target module in the library file, although it is a selective copy, But for a small program, copying some. lib files can still cause some waste of memory resources. To solve these problems, smart people create dynamic link shared libraries, dynamic libraries are files with the. dll extension in Windows (well, now it's time to explain the problem raised in the preface), remember that the dynamic library link is done by the dynamic linker, but he also needs a static linker. Look back to explain).

Here to explain, continue to preface the narration, a dynamic link library contains. h,. lib,. dll files, and the true relocatable target module is placed in a. dll. Hey. Just when we talked about the static link library, the relocatable target module is placed in. lib, where in the dynamic library it is placed in a. dll, so why do I need a. lib file? What exactly is in this. lib file? This is the design needs of the dynamic linker.

The link process of a dynamic linker is mainly divided into two steps: generating partially linked executable target files, generating fully linked executables, which have static linker and dynamic linker completion (this process can be referred to in the in-depth understanding of computer system P468 figure 7-15).

This generates a partially linked executable target file that has a static linker complete and needs to use the. lib file. The. lib file does not contain any code and data content about the dynamic library file, but contains some relocation and symbolic table information, which enables the runtime to resolve references to code and data in a. dll library file. So that explains what I explained in the preface. After the link to the. lib file, the program compiles without problems.

After completing some of the links, you have generated an executable target file, is an. exe file in Windows, but this is only a partially linked executable object file. It does not contain any database-related data and code content, the direct operation of course will be the error, and the error message is missing the corresponding. dll file, here, as long as the corresponding. dll file with the generated part of the linked executable target file in the same Directory, the program can be run, perfect. Hey. The whole dynamic link process is still not referencing or copying the code and data content in the library file (. dll). How can the program run again? That's because when you execute the. exe file, the program loader dynamically loads the. dll dynamic library file and then runs with the. exe file, which is what the loader does for you, so you can't see it.