DLL symbol identity

[Benjamin Thaut via Digitalmars-d]

On Wednesday, 13 May 2015 at 12:57:35 UTC, Logan Capaldo wrote:
>
> a.dll provides symbol s1
> b.dll provides symbol s1
>
> c.dll imports symbol s1 from a.dll, provides symbol s2
> d.dll imports symbol s1 from b.dll, provides symbol s3
>
> e.exe imports symbol s2 from c.dll, imports symbol s3 from 
> d.dll. e.exe only needs the import libs from c.dll and d.dll.
>
> You're patching the import tables at runtime correct?. If you 
> patch c and d's import tables their s1 import is going to end 
> up pointing at the same symbol.
>
> I can build a.dll and c.dll completely independently of d.dll 
> and b.dll. There's no opportunity to prevent this at compile 
> time. Likewise e.exe doesn't know or care s1 exists so it 
> builds fine as well. You don't need a.lib or b.lib to build 
> e.exe.

Yes, but exactly the same behavior is currently in place on 
linux. Also your example is quite a corner case, the usual use 
case where you wan't symbols of multiple instances of the same 
template to be merged is more common. I don't see any real use 
case in D where it would be important that the duplicated s1 
symbols are not merged. Non D dlls will not be touched and if you 
really need that behavior you can always put your non D code in a 
seperate Dll to avoid this behavior.