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