DLL symbol identity

[Benjamin Thaut via Digitalmars-d]

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.

If you define the same type within the same module but it behaves 
differently depending on where it is used (e.g. depending on 
compiler flags -version -debug etc), this is already an issue and 
will also explode with static libraries. So nothing new here. The 
user of the language has to ensure that all uses of a type see 
the same declaration of the type.

>
> 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.