DLL symbol identity

[Logan Capaldo via Digitalmars-d]

On Wednesday, 13 May 2015 at 06:17:36 UTC, Benjamin Thaut wrote:
> On Tuesday, 12 May 2015 at 17:48:50 UTC, Logan Capaldo wrote:
>> q could be a completely different type in a.dll vs. c.dll. 
>> Please correct me if I am wrong, but my understanding of how 
>> import libs get used you can't detect this at build time and 
>> disallow it. Linking d.exe we have no reason to look at a.lib 
>> and notice the conflict, and even if we did there's no type 
>> information to go off of anyway and you could assume that they 
>> were the same.
>
> No q can not be a different type in a.dll vs c.dll
> Because of the mangling of the type it would be called a.q once 
> and c.q so no conflict would arise.
>

Not if q is extern C or extern C++.

>>
>> Is your intent to only apply this unification to extern (D) 
>> symbols?
> Why not? I can't think of anything special about extern (D) 
> declarations. Just as a reminder, linux already does this for 
> _all_ symbols. And it doesn't cause any issues there.

The thing that is special about extern (D) symbols is that the 
module mangling sidesteps my 'q' example.

It does cause issues on Linux actually. I've seen it multiple 
times, usually when first party code and third party both 
unbeknownst to each other both embed different versions of a 
popular source only library.

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?