visual studio - Why does LINK.EXE need a .EXP file to accommodate circular dependencies among .DLL files? -

note: cases of .lib refer link.exe import libraries, rather collections of object files.

i've spent long time figuring out how 1 accommodates circular dependencies among .dll files in windows. it's because i'm working makefile having unresolved externals amongst circularly dependent shared libraries. figured needed understand more linker...

i'm going recap little, because it's quite easy forget. not this, there's high chance there issues in understanding of linking in windows. corrections helpful.

for sake of question, have 3 files: exec.obj, one.obj, , two.obj.

scenario:

1. one.obj contains symbol defined in two.obj , processed link.exe .dll.
2. two.obj contains symbol defined in one.obj , processed link.exe .dll.
3. exec.obj contains symbols defined in both one.obj , two.obj , processed link.exe .exe.

a common circular dependency problem:

when one.obj processed link.exe, one.dll , one.lib (import library) created. purpose of one.lib describe location of exported symbols found within one.dll.

at current point in time, one.dll cannot import symbols two.obj because two.obj hasn't been processed link.exe , two.lib (import library) doesn't exist yet. because of this, one.dll contains unresolved references symbols defined in two.obj.

just one.obj, when two.obj processed link.exe, creates import library (two.lib) , two.dll. however, two.obj can find it's own unresolved references looking inside one.lib. @ point, one.dll has unresolved references, , two.dll doesn't. either way, exec.obj have unresolved references when processed.

a common circular dependency solution:

the problem whenever try link one.obj .dll, searches unresolved references, turns one.obj .dll , creates corresponding one.lib (import library) in same step. once step complete, it's late search other unresolved references because one.obj one.dll.

the solution breaking down steps. creating corresponding import library (one.lib) without turning one.obj one.dll. allow one.obj processed link.exe @ later time, not disabling it's ability use two.lib when two.obj linked.

the question:

when creating corresponding import library (one.lib) in it's own single step using lib.exe, file called one.exp created. don't see why it's necessary. if one.obj still exists, can find it's unresolved references in two.lib when two.obj processed. however, i've read, it's necessary include one.exp in final step. instead of processing one.obj , having find two.lib, one.exp has added list of files fed link.exe. why? two.lib describes symbols needed one.obj , two.exp never needed process two.obj.

you have rewind clock late 1980s, when exports specified linker's /def or /export options. make second link step produce one.dll brittle, you'll shoot leg off when don't use exact same options. avoided linking one.exp, , omitting options, no longer possible them wrong , linker won't rewrite one.lib

not relevant anymore, uses __declspec(dllexport) attribute today specify exports. don't see obvious failure scenario when don't link one.exp in case, other having one.lib filedate newer two.dll , causing rebuilt unnecessarily. not sure, never once got myself pickle this.