DLL symbol identity

[Logan Capaldo via Digitalmars-d]

On Wednesday, 13 May 2015 at 11:41:27 UTC, Benjamin Thaut wrote:
> On Wednesday, 13 May 2015 at 11:27:18 UTC, Logan Capaldo wrote:
>>
>> Yes it won't happen for explicit LoadLibrary's and 
>> GetProcAddresses, but COM or other plugin systems is an 
>> example of a situation where many DLLs may expose the same 
>> named symbols with different definitions, and there may be 
>> situations where people link to those DLLs directly to get 
>> other things they provide.
>
> Once again, I'm going to patch the import table. The import 
> table gets only generated for symbosl which are _imported_ by a 
> import library. This only happens for things that get imported 
> by D libraries / executables. Linking against multiple dlls via 
> a import library which export the same symbol doesn't work no 
> matter if I do the patching or not. So nothing changes in that 
> regard. Your COM Dlls are not going to break even if each COM 
> dll exports the same symbol. Because these COM specific symbols 
> will not be imported by a D library via a import library, so 
> nothing changes. The problems you think exist do not exist 
> because I only patch the importing table and not the dlls that 
> export the symbols. Even if you mix D with C++ you are not 
> going to have that problem, because you can't link against 
> multiple libraries with the same symbol with C++ either.

a.dll provides symbol s1
b.dll provides symbol s1

c.dll imports symbol s1 from a.dll, provides symbol s2
d.dll imports symbol s1 from b.dll, provides symbol s3

e.exe imports symbol s2 from c.dll, imports symbol s3 from d.dll. 
e.exe only needs the import libs from c.dll and d.dll.

You're patching the import tables at runtime correct?. If you 
patch c and d's import tables their s1 import is going to end up 
pointing at the same symbol.

I can build a.dll and c.dll completely independently of d.dll and 
b.dll. There's no opportunity to prevent this at compile time. 
Likewise e.exe doesn't know or care s1 exists so it builds fine 
as well. You don't need a.lib or b.lib to build e.exe.