DLL symbol identity
Logan Capaldo via Digitalmars-d
digitalmars-d at puremagic.com
Wed May 13 06:50:51 PDT 2015
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".
More information about the Digitalmars-d
mailing list