runtime loading D shared library as a standalone (with it's own GC etc)

Timothee Cour thelastmammoth at gmail.com
Mon Mar 3 22:28:34 PST 2014


On Fri, Feb 28, 2014 at 10:27 AM, Martin Nowak <code at 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
 ...
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puremagic.com/pipermail/digitalmars-d-learn/attachments/20140303/1b367d1e/attachment-0001.html>


More information about the Digitalmars-d-learn mailing list