DIP45: fixing the dllimport/dllexport issue

[Benjamin Thaut]

Am 29.08.2013 21:20, schrieb Martin Nowak:
> On 08/29/2013 09:12 PM, Martin Nowak wrote:
>> On 08/29/2013 12:03 PM, Benjamin Thaut wrote:
>>> But what if you import a module that is linked statically? That would
>>> mean export would be treated as dllimport and it will fail to link
>>> because the _imp_ symbols are missing when linking statically?
>>
>> Could we create alias symbols?
>
> Indeed this seems to work.
> OMF has an ALIAS record (http://www.azillionmonkeys.com/qed/Omfg.pdf)
> and COFF has weak externals (http://blog.omega-prime.co.uk/?p=121).
>
> So we could add _imp_* aliases for every exported symbol.
> When someone links against the import library they are never used, when
> someone links against a static library they redirect to the actual
> definitions. Would that work?

Well no its not that simple. You can't just alias it. You still have to 
create a import table. That would mean ALL data accesses to data symbols 
would have another level of indirection. Always. The _imp_ symbols don't 
refer to the data directly, they refer to the location the data is 
stored at. As explained in the article I linked 
(http://blog.omega-prime.co.uk/?p=115) this requires different assembly 
to be generated. To make this work we would always have to generate 
assembly with one level of indirection added for every data symbol 
access, because we can not know if the symbol might be imported from a 
DLL or not. As D tries to achive near C++ performance I would arther 
want to avoid that.