Thread overview
runtime loading D shared library as a standalone (with it's own GC etc)
Feb 26, 2014
Timothee Cour
Feb 26, 2014
Adam D. Ruppe
Feb 27, 2014
Timothee Cour
Feb 28, 2014
Martin Nowak
Mar 04, 2014
Timothee Cour
May 23, 2014
Martin Nowak
February 26, 2014
Currently (on OSX) I can runtime load a D dll from a C program, but not from a D program, which seems silly.

Is it possible to runtime load a D shared library as a standalone (ie without sharing GC, runtime or any other data), treating it as if we were loading from a C program (making no attempt at sharing druntime or otherwise).

What do I need to change in druntime to make this possible?


February 26, 2014
Try compiling your library with -defaultlib= (leaving it blank after the equal sign). Then it might work by not loading the symbols for phobos etc twice - they will only be linked into the main program.
February 27, 2014
On Wed, Feb 26, 2014 at 1:20 PM, Adam D. Ruppe <destructionator@gmail.com>wrote:

> Try compiling your library with -defaultlib= (leaving it blank after the equal sign). Then it might work by not loading the symbols for phobos etc twice - they will only be linked into the main program.
>

Thanks, but I don't see how that would help treating the D dll as a standalone library with its own GC/druntime etc. Once again, I'm doing runtime loading (via dlopen+friends) not load-time linking (via -L-lfoo compile flags).

Furthermore, the following:
dmd -oflibfoo.dylib -shared -defaultlib= foo.d
results in link errors (because of '-defaultlib= ')

and I also tried:
dmd -offoo.o -c foo.d
gcc foo.o -shared -o libfoo.dylib -Wl,-flat_namespace -Wl,-undefined
-Wl,suppress

followed by runtime loading it in a D program (via dlopen) but not
surprisingly this crashes.


February 28, 2014
On 02/26/2014 10:16 PM, Timothee Cour wrote:
> Currently (on OSX) I can runtime load a D dll from a C program, but not
> from a D program, which seems silly.
>
> Is it possible to runtime load a D shared library as a standalone (ie
> without sharing GC, runtime or any other data), treating it as if we
> were loading from a C program (making no attempt at sharing druntime or
> otherwise).
>
> What do I need to change in druntime to make this possible?
>
Depends on why it doesn't work.
March 04, 2014
On Fri, Feb 28, 2014 at 10:27 AM, Martin Nowak <code@dawg.eu> wrote:

> On 02/26/2014 10:16 PM, Timothee Cour wrote:
>
>> Currently (on OSX) I can runtime load a D dll from a C program, but not from a D program, which seems silly.
>>
>> Is it possible to runtime load a D shared library as a standalone (ie without sharing GC, runtime or any other data), treating it as if we were loading from a C program (making no attempt at sharing druntime or otherwise).
>>
>> What do I need to change in druntime to make this possible?
>>
>>  Depends on why it doesn't work.
>


Here's an example.
If it works from inside C++ there should be a way to make it work from
inside D isn't there?  (eg by isolating the GC of the shared library from
the GC of the main program, etc).

main.d:
call a D shared library via dlopen/dlsym
foo.d:
extern(C) void foo(){
  printf("inside_foo\n"); //ok
  import core.runtime;
  bool ret=Runtime.initialize();//will segfault below with or without that
  assert(ret);//ok
  int[]a;
  a.length=2;//segfault
}


dmd -g -oflibfoo.dylib -shared foo.d
dmd -g -oftest main.d
./test
#Loading shared libraries isn't yet supported on OSX.
#inside_foo
#segfault at first occurence of gc (a.length=2 above)

under lldb:

* thread #1: test D2rt12sections_osx9tlsOffsetFPvZm + 109, stop reason =
EXC_BAD_ACCESS (code=EXC_I386_GPFLT)
    frame #0: test D2rt12sections_osx9tlsOffsetFPvZm + 109
    frame #1:  test __tls_get_addr + 20
    frame #2:  libfoo.dylib _d_arraysetlengthT + 3701
 ...


May 23, 2014
Filed as https://issues.dlang.org/show_bug.cgi?id=12792.