DLL symbol identity

[Logan Capaldo via Digitalmars-d]

On Wednesday, 13 May 2015 at 07:49:26 UTC, Benjamin Thaut wrote:
> On Wednesday, 13 May 2015 at 07:41:27 UTC, Logan Capaldo wrote:
>>
>> If my program only links against DLLs written in D, sure this 
>> is no worse than the static library/version flag situation. 
>> But one of D's features is C and C++ interop. For instance if 
>> I link against a DLL that happens to provide COM objects am I 
>> going to start getting weird behaviors because all the 
>> DllGetClassObjects are 'unified' and we just pick one?
>
> Well this unification will only happen for D libraries. Its not 
> going to do that for non D shared libraries (e.g. written in C 
> or C++).

And for shared libraries written in a mix of D and C++ or C, or 
shared libraries written in D but that expose extern (C) or 
extern (C++) symbols?

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.