D shared libraries

Unknown W. Brackets unknown at simplemachines.org
Sat Apr 12 13:29:41 PDT 2008


I seem to remember they, essentially, share a GC.  I do think they can 
get confused/trip over each other if you're not careful.

Generally, I've just had two functions I call into the so with, which 
init/deinit the library.  To reduce complications and problems like 
you're seeing, I keep the plugins as simple as possible.

IIRC, they share the same gc handle already.  It's possible they both 
may run the gc when they shutdown.  I'd use the functions in std.gc and 
assembler output to debug...

Unfortunately this is one area where D (mostly in its available tools) 
is lacking currently...

-[Unknown]


BB wrote:
> Thanks very much, that worked.
> 
> After being able to call into the .so, I see a segmentation fault at the 
> end of main().  Through gdb I see it's crashing in _d_callfinalizer(). 
> Locally explicitly deleting the object allocated by the .so also results 
> in a sigsegv.  However, calling into the .so to delete the object works 
> fine.
> 
> What is the reasoning for this - is it that the gc is statically linked 
> into both the .so and the executable, so sharing a reference causes the 
> local gc to try and clean it up?  If so, what are the guidelines/rules 
> to use?
> 
> Thanks again.
> 
> 
> Unknown W. Brackets wrote:
>> To compile a shared library, Linux using gdc:
>>
>> gdmd -op -oflibxyz.so.1.0.1 lib.d -fPIC -q,-rdynamic,-shared
>> gdmd -op main.d -fPIC -q,-rdynamic -L-ldl
>>
>> Compiling a shared library on Windows is a bit more complicated 
>> (although possible with dmd and phobos as they are.) It involves 
>> DllMain and def files...
>>
>> Please note, if you have selinux you may have have to run chcon.
>>
>> -[Unknown]
>>
>>
>> BB wrote:
>>> Tried this on D.gnu but didn't get an answer. Any feedback here?
>>> ------------------------------------------------------------------
>>>
>>>
>>> From what I read on newsgroups, this should be possible with gdc on 
>>> linux? Goal is a plugin type solution. With the following code, I 
>>> compile intf.d and lib.d together into a shared library, and intf.d 
>>> and main.d into an executable. Compiles/links fine. When I run it, I 
>>> get a message like:
>>>
>>> Null library handle: libxyz.so.1.0.1: undefined symbol: __data_start
>>>
>>> I compiled the .d files with -fPIC and the .so with:
>>> gcc -shared -Wl,-soname,libxyz.so.1 -fPIC.
>>>
>>> Is this definitely possible, and if so, what am I doing wrong? I 
>>> tried gdc 0.24 and the latest off svn with the same results.
>>>
>>> TIA.
>>>
>>> -------------------------------------------------------------
>>>
>>> intf.d:
>>> =========
>>> module intf;
>>> public interface I { public int getId(); }
>>>
>>> lib.d:
>>> =========
>>> module lib;
>>> import intf;
>>> class A : I { public int getId() { return 42; } }
>>> extern (C) { I getObj() { return new A(); } }
>>>
>>> main.d:
>>> ==========
>>> ...
>>> void main(char[][] args)
>>> {
>>> void* hnd = dlopen(toStringz("libxyz.so.1.0.1"), RTLD_NOW);
>>> if (hnd == null) {
>>> printf("Null library handle: %s\n", dlerror());
>>> return 0;
>>> }
>>> ...
>>> }
>>>
>>>
>>>
> 
> 



More information about the Digitalmars-d mailing list