DLL symbol identity

[Logan Capaldo via Digitalmars-d]

On Friday, 8 May 2015 at 05:26:01 UTC, Benjamin Thaut wrote:
> I personally would prefer option 2 because it would be easier 
> to use and wouldn't cause lots of additional maintenance effort.
>
> Any opinions on this? As both options would be quite some work 
> I don't wan't to start blindly with one and risking it being 
> rejected later in the PR.
>
> Kind Regards
> Benjamin Thaut


(2) would be nice but how would

a.dll provides a.dll!q

b.dll links against a.dll, provides b.dll!w

c.dll provides c.dll!q

d.exe links against b.dll (b.lib) and c.dll (c.lib).

work?

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.

Is your intent to only apply this unification to extern (D) 
symbols?