DLL symbol identity

[Logan Capaldo via Digitalmars-d]

On Wednesday, 13 May 2015 at 13:31:15 UTC, Benjamin Thaut wrote:
> 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.

Imagine a is msvcr90.dll and b is msvcr100.dll. Or a is 
msvcrt.dll. Or a is mfc100u.dll and b is mfc110u.dll. This 
happens all the time, and all we need is for c and d to have a 
little bit of D in them.

Linux (thankfully) doesn't typically have N versions of libc 
floating around.

I _think_ if you only do this for D-mangled symbols you'll get 
99% of the benefits (doing the right things for templates etc.) 
without causing problems for the "corner cases".