DMD, LDC, shared objects, rpath

[kinke via digitalmars-d-ldc]

On Thursday, 22 June 2017 at 11:00:52 UTC, bachmeier wrote:
> On Wednesday, 21 June 2017 at 21:19:44 UTC, David Nadlinger 
> wrote:
>
>> As far as I am aware, no compiler has seamless support for 
>> DLLs right now (see e.g. Benjamin Thaut's talk from last 
>> year's DConf). If the current half-baked DLL support is harder 
>> to use from LDC than from DMD, it's certainly something that 
>> can be fixed quite easily – the question is just whether it's 
>> worth it.
>>
>>  — David
>
> It's easy enough to create a DLL with LDC, but C programs can't 
> find those functions.

Nope, that should definitely work (exporting/importing functions 
via `export` visibility). Just verified with LDC 1.3-beta2 on 
Win64:

D:
import core.stdc.stdio;
export extern(C) void exportedFoo() { printf("exportedFoo()\n"); }

C:
extern "C" void exportedFoo();
int main(int argc, char** argv)
{
     exportedFoo();
     return 0;
}

ldc2 -shared dmodule.d => generates dmodule.{dll,lib,exp}
cl cppmodule.cpp dmodule.lib => generates cppmodule.exe relying 
on dmodule.dll

Produces the expected output.

As David mentioned, being able to use a single shared runtime 
(druntime/Phobos DLLs) for multiple D binary modules and getting 
full C++ DLL interop to work is a whole different beast, 
requiring among other things a language change (`export`: from 
visibility to stand-alone attribute).