On Wednesday, 13 May 2015 at 11:41:27 UTC, Benjamin Thaut wrote:
On Wednesday, 13 May 2015 at 11:27:18 UTC, Logan Capaldo wrote:
Yes it won't happen for explicit LoadLibrary's and
GetProcAddresses, but COM or other plugin systems is an
example of a situation where many DLLs may expose the same
named symbols with different definitions, and there may be
situations where people link to those DLLs directly to get
other things they provide.
Once again, I'm going to patch the import table. The import
table gets only generated for symbosl which are _imported_ by a
import library. This only happens for things that get imported
by D libraries / executables. Linking against multiple dlls via
a import library which export the same symbol doesn't work no
matter if I do the patching or not. So nothing changes in that
regard. Your COM Dlls are not going to break even if each COM
dll exports the same symbol. Because these COM specific symbols
will not be imported by a D library via a import library, so
nothing changes. The problems you think exist do not exist
because I only patch the importing table and not the dlls that
export the symbols. Even if you mix D with C++ you are not
going to have that problem, because you can't link against
multiple libraries with the same symbol with C++ either.
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.
