动态链接 linux xp 对应的结构图 及比较 及 比较英文原版
Figure 2: An ELF shared library
(Lots of pointer arrows here)
66：dynamic的控制作用。 Test …plt ….跨got..
微软版本，
输入表：
Figure 5: Structure of .edata section
66：原来 放大到段是 .edata段，然后那个 这是 输出表。
根据修养以一书（p257）是，pe文件头中的dataDiretcoty..（类似段表结构）…first 元素是 image_export_directory…(依然是dircetory)
阅读英文的三点总结
The Windows scheme is arguably faster, since it doesn't have to map and relocate the dynamic linker in each
process before it starts linking
//66速度
The ELF scheme tries considerably harder than the PE scheme to maintain the semantics of static linked
programs.
//elf 绝对的data 处理的很好。。 pe处理的不知。
The ELF scheme uses a single name space per program, while the PE scheme uses a name space per library.
//结果是elf全局观。看得到 同名的函数的最新版本。而pe不能，他不知道符号在哪个模块。
阅读原文
Comparison of dynamic linking approaches
The Unix/ELF and Windows/PE dynamic linking differ in several interesting ways.
The ELF scheme uses a single name space per program, while the PE scheme uses a name space per library. An ELF executable lists the symbols it needs and the libraries it needs, but it doesn't record which symbol is in which library. A PE file, on the other hand, lists the symbols to import from each library. The PE scheme is less flexible but also more resistant to inadvertent spoofing. Imagine that an executable calls routine AFUNC which is found in library A and BFUNC which is found in library B. If a new version of library A happens to define its own BFUNC, an ELF program could use the new BFUNC in preference to the old one, while a PE program wouldn't. This is a problem with some large libraries; one partial solution is to use the poorly documented DT_FILTER and DT_AUXILIARY fields to tell the dynamic linker what libraries this one imports symbols from, so the linker will search those libraries for imported symbols before searching the executable and the rest of the libraries. The DT_SYMBOLIC field tells the dynamic linker to search the library's own symbol table first, so that other libraries cannot shadow intra-library references. (This isn't always desirable; consider the malloc hack described in the previous chapter.) These ad-hoc approaches make it less likely that symbols in unrelated libraries will inadvertently shadow the correct symbols, but they're no substitude for a hierarchical link-time name space as we'll see in Chapter 11 that Java has.
The ELF scheme tries considerably harder than the PE scheme to maintain the semantics of static linked programs. In an ELF program, references to data imported from another library are automatically resolved, while a PE program needs to treat imported data specially. The PE scheme has trouble comparing the values of pointers to functions, since the address of an imported function is the address of the "thunk" that calls it, not the address of the actual function in the other library. ELF handles all pointers the same.
At run-time, nearly all of the Windows dynamic linker is in the operating system, while the ELF dynamic linker runs entirely as part of the application, with the kernel merely mapping in the initial files.
The Windows scheme is arguably faster, since it doesn't have to map and relocate the dynamic linker in each process before it starts linking. The ELF scheme is definitely a lot more flexible. Since each executable names the "interpreter" program (now always the dynamic linker named ld.so) to use, different executables could use different interpreters without requring any operating system changes. In practice, this makes it easier to support executables from variant versions of Unix, notably Linux and BSD, by making a dynamic linker that links to compatibility libraries that support non-native executables.
===后续
http://www.iecc.com/linker/linker10.html
有比较--linux pe
http://www.iecc.com/linker/
串联的好！！。。。尤其是连线