Shared library in D on Linux

Timo Westkämper" <timo.westkamper at gmail.com> Timo Westkämper" <timo.westkamper at gmail.com>
Mon Apr 9 13:31:43 PDT 2012


On Monday, 9 April 2012 at 19:59:18 UTC, Iain Buclaw wrote:
> On 9 April 2012 20:37,  <"Timo Westkämper\"
> <timo.westkamper at gmail.com>"@puremagic.com> wrote:
>> On Monday, 9 April 2012 at 15:14:45 UTC, Ellery Newcomer wrote:
>>>
>>> Well, if you're really hankering for a shared lib, try ldc. I 
>>> have gotten
>>> it to compile working shared libs in the past.
>>>
>>> On 04/09/2012 01:24 AM, "Timo Westkämper" 
>>> <timo.westkamper at gmail.com>"
>>> wrote:
>>>>
>>>> On Sunday, 8 April 2012 at 17:59:28 UTC, Timo Westkämper 
>>>> wrote:
>>>>>
>>>>> Does someone know why the lib (.a) packaging instead of 
>>>>> objects (.o)
>>>>> works better in this case?
>>>>
>>>>
>>>> Didn't work after all with -lib. I mixed up outputs.
>>
>>
>> Thanks, I might switch to ldc, if dmd and gdc fail here.
>>
>> I found this tls.S script in the druntime sources 
>> (src/rt/tls.S). Do you
>> think it could be included in the library to make tls 
>> initialization work?
>>
>> #if linux
>>
>> /* The memory between the addresses of _tlsstart and _tlsend 
>> is the storage
>> for
>>  * thread-local data in D 2.0.  Both of these rely on the 
>> default linker
>> script
>>  * of:
>>  *      .tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
>>  *      .tbss  : { *(.tbss .tbss.* .gnu.linkonce.tb.*) 
>> *(.tcommon) }
>>  * to group the sections in that order.
>>  *
>>  * Sadly, this does not work because ld orders .tdata after 
>> .tdata.*,
>> despite
>>  * what the linker script says.
>>  */
>>
>> .file "tls.S"
>>
>> .globl _tlsstart
>>    .section .tdata,"awT", at progbits
>>    .align 4
>>    .type   _tlsstart, @object
>>    .size   _tlsstart, 4
>> _tlsstart:
>>    .long   3
>>
>> .globl _tlsend
>>    .section .tcommon,"awT", at nobits
>>    .align 4
>>    .type   _tlsend, @object
>>    .size   _tlsend, 4
>> _tlsend:
>>    .zero   4
>>
>> #endif
>>
>>
>
> That assembly file does nothing for shared library support.  I 
> have
> been meaning to finish up a solution to help support shared 
> libs,
> would mean more deviation from the dmd compiler's runtime 
> library, but
> that's fine.

Ok. Good to know. Here is what I came up with for now.

I have not yet much knowledge of DMD internals so I just played 
around with declarations:

import std.stdio;

// FIXME
__gshared extern(C) void* __data_start;

// FIXME tls marks
extern(C) int _tlsstart;
extern(C) int _tlsend;

// FIXME exception handling markers
extern(C) void _deh_beg() { }
extern(C) void _deh_end() { }

// hooks for init and term
extern (C) void rt_init();
extern (C) void rt_term();

extern (C) void hiD() {
   rt_init();
   writeln("hi from D lib");
   rt_term();
}

//void main();

/*extern(C) {

   void _init() {
     rt_init();
   }

   void _fini() {
     rt_term();
   }

}*/


For some reasons, the _init and _fini parts don't yet work 
properly.

And here the part of the Makefile that created the library:

   dmd -c -g test.d -fPIC
   ld -shared -o libtest.so test.o -lrt -lphobos2 -lpthread

This mostly reflects Jacob Carlborg's comment in the beginning of 
what features are still missing

* Proper initialization of TLS data
* Setting up exception handling tables
* Setting up module info


More information about the Digitalmars-d mailing list