First Draft: Symbol Representation (Export)

Richard (Rikki) Andrew Cattermole richard at cattermole.co.nz
Fri Mar 8 18:53:26 UTC 2024


On 09/03/2024 5:49 AM, Tim wrote:
> On Thursday, 29 February 2024 at 11:15:07 UTC, Richard (Rikki) Andrew 
> Cattermole wrote:
>> D's support for shared libraries has historically presented challenges 
>> for users, especially when dealing with complex use cases. This 
>> proposal aims to improve the user experience by establishing a user 
>> story that will provide a consistent and user-friendly approach to 
>> usage and compilation of binaries without a thorough understanding of 
>> linkers.
>>
>> With the recent resolution of dmd's exportation support on Windows 
>> (druntime support is still under development), we are now ready to 
>> focus on making D's shared library capabilities more accessible and 
>> usable for common use cases.
>>
>> Links: 
>> [current](https://gist.githubusercontent.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e/11e36e8a332324c5323792da2835337d0306a6c9) [latest](https://gist.github.com/rikkimax/1d7cfdb8ed74e9e4efc9ba0208f42e7e)
> 
> Can a module, which is compiled as part of the application, still 
> contain prototypes for symbols from a DLL? Here is an example:
> ```D
> extern(C++) void foo(const char *s, size_t length);
> void foo(string s)
> {
>      foo(s.ptr, s.length);
> }
> ```
> 
> Function `foo` is implemented in a C++ library, which could be compiled 
> as a DLL. The module contains a prototype for the function, but also an 
> overload with a more convenient interface for D. The module needs to be 
> compiled, because it contains the overload. Can the prototype still be 
> imported from a DLL and be part of the same module?

Yes.

Mangling and ABI is left untouched.

About the only thing you need to deal with is setting a symbol into 
DllImport mode, which is already something you are meant to be doing.

With this you can set it via ``export extern``, ``export(none)`` or when 
using an import path use ``-extI`` and have it ``export``.

You can get away with using internal symbol mode because Windows will 
generate a wrapper function that is in internal mode as part of the 
import library.

There is no difference in internal vs DllImport symbol modes on non-Windows.


More information about the dip.development mailing list