首先，原文地址如下：

http://www.quora.com/Systems-Programming/What-is-the-exact-difference-between-Dynamic-loading-and-dynamic-linking

翻譯內(nèi)容如下：

動(dòng)態(tài)裝入(Dynamic loading) 指的是當(dāng)一個(gè)進(jìn)程啟動(dòng)后，將一個(gè)可執(zhí)行的文件（原文是executable，我理解為磁盤上的文件 或者駐留在內(nèi)存中的例程）或庫映射到（或者不常發(fā)生的復(fù)制）到進(jìn)程內(nèi)存空間。動(dòng)態(tài)鏈接 (dynamic linking)指的是在編譯（匯編）之后，分解字符（resolving symbols）——把名字和地址或者偏移量聯(lián)系起來。這兩者難以區(qū)分的原因是，大約在進(jìn)程啟動(dòng)后，編譯（匯編）之后這兩個(gè)過程，通常對(duì)二者的微妙區(qū)別不加區(qū)分地一起完成。大概最清晰的方式來解釋這二者的區(qū)別就是分別展示二者的各種組合在實(shí)踐中意味著什么。

動(dòng)態(tài)裝入，靜態(tài)鏈接。

可執(zhí)行的文件擁有一個(gè)在編譯時(shí)生成的 地址/偏移量表，但是實(shí)際的代碼/數(shù)據(jù)在進(jìn)程剛啟動(dòng)時(shí)沒有裝到內(nèi)存中。這并不是大多數(shù)現(xiàn)在的操作系統(tǒng)的處理方式，但是它可能描述了一些老式的overlay systems.如果現(xiàn)在的嵌入式系統(tǒng)也使用這種方式，我一點(diǎn)也不感覺到奇怪。無論是哪種情況，其目的都是給予程序員內(nèi)存控制的自由同時(shí)避免運(yùn)行時(shí)的鏈接花費(fèi)。

靜態(tài)裝入，動(dòng)態(tài)鏈接

這通常是在編譯時(shí)確定動(dòng)態(tài)庫的工作方式。可執(zhí)行文件包含動(dòng)態(tài)/共享庫的引用，但是字符表（symbol table）沒有或者不完整。裝入和鏈接都在進(jìn)程啟動(dòng)時(shí)進(jìn)行，被認(rèn)為是“動(dòng)態(tài)的”鏈接但不是“動(dòng)態(tài)的”裝入。

動(dòng)態(tài)裝入，動(dòng)態(tài)鏈接

這是你調(diào)用dlopen或其他系統(tǒng)里的等價(jià)調(diào)用的時(shí)候發(fā)生的事情。object(.obj)文件在程序的控制下動(dòng)態(tài)裝入（也就是開始之后），包括調(diào)用程序和庫里的字符都根據(jù)那個(gè)時(shí)刻進(jìn)程的可能獨(dú)一無二的內(nèi)存布局進(jìn)行解析（把名字和地址/偏移量聯(lián)系起來）.

靜態(tài)裝入，靜態(tài)鏈接

所有的東西都在編譯時(shí)解析完成。進(jìn)程開始的時(shí)候所有東西都立即加載到內(nèi)存中，不需要其他的解析（鏈接linking）。概括地說，加載發(fā)生自單個(gè)文件是不必要的，但是我認(rèn)為實(shí)際的格式或者實(shí)現(xiàn)并不能夠在不使用動(dòng)態(tài)鏈接的情況下實(shí)現(xiàn)多文件的裝入。

原文內(nèi)容如下

Dynamic loading refers to mapping (or less often copying) an executable or library into a process's memory after is has started.  Dynamic linking refers to resolving symbols - associating their names with addresses or offsets - after compile time.  The reason it's hard to make a distinction is that the two are often done together without recognizing the subtle distinctions around the parts I put in bold.  Perhaps the clearest way to explain is to go through what the different combinations would mean in practice.

• Dynamic loading, static linking.  The executable has an address/offset table generated at compile time, but the actual code/data aren't loaded into memory at process start.  This is not the way things tend to work in most systems nowadays, but it would describe some old-fashioned overlay systems.  I'd also be utterly unsurprised if some current embedded systems work this way too.  In either case, the goal is to give the programmer control over memory use while also avoiding the overhead of linking at runtime.
• Static loading, dynamic linking.  This is how dynamic libraries specified at compile time usually work.  The executable contains a reference to the dynamic/shared library, but the symbol table is missing or incomplete.  Both loading and linking occur at process start, which is considered "dynamic" for linking but not for loading.
• Dynamic loading, dynamic linking.  This is what happens when you calldlopen or its equivalent on other systems.  The object file is loaded dynamically under program control (i.e. after start), and symbols both in the calling program and in the library are resolved based on the process's possibly-unique memory layout at that time.
  
• Static loading, static linking.  Everything is resolved at compile time.  At process start everything is loaded into memory immediately and no extra resolution (linking) is necessary.  In the abstract it's not necessary for the loading to occur from a single file, but I don't think the actual formats or implementations (at least those I'm familiar with) can do multi-file loading without dynamic linking.