DLL symbol identity

[Benjamin Thaut via Digitalmars-d]

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.