• Timothee Cour (7/7) Feb 26 2014 Currently (on OSX) I can runtime load a D dll from a C program, but not
• Adam D. Ruppe (4/4) Feb 26 2014 Try compiling your library with -defaultlib= (leaving it blank
• Timothee Cour (14/17) Feb 26 2014 Thanks, but I don't see how that would help treating the D dll as a
• Martin Nowak (2/9) Feb 28 2014 Depends on why it doesn't work.
• Timothee Cour (29/41) Mar 03 2014 Here's an example.
• Martin Nowak (1/1) May 23 2014 Filed as https://issues.dlang.org/show_bug.cgi?id=12792.

Timothee Cour <thelastmammoth gmail.com> writes:

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?

"Adam D. Ruppe" <destructionator gmail.com> writes:

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.

Timothee Cour <thelastmammoth gmail.com> writes:

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.

Martin Nowak <code dawg.eu> writes:

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.

Timothee Cour <thelastmammoth gmail.com> writes:

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:


EXC_BAD_ACCESS (code=EXC_I386_GPFLT)



 ...

"Martin Nowak" <code dawg.eu> writes:

Filed as https://issues.dlang.org/show_bug.cgi?id=12792.