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.
