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