www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Shared library in D on Linux

reply "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
I am still testing which setup gives me reliable shared D 
libraries which can be used from C.

Here is my latest test:

* test.d:
import std.stdio;
extern (C) {
   void hiD() {
     writeln("hi from D lib");
   }
}

* main.c
#include <stdio.h>
#include <dlfcn.h>
#include <stdlib.h>
void main() {
     void (*hiD)(void);
     void* handle = dlopen("./libtest.so", RTLD_LAZY);
     if (handle == NULL) {
         printf("%s\n", dlerror());
         exit(1);
     }	
     hiD = dlsym(handle, "hiD");
     if (hiD != NULL) {
         hiD();
     } else {
         printf("hiD is null\n");
     }
     dlclose(handle);
}

* Makefile

test:
	#gdc-4.6 -g -c test.d -fPIC -o test.o
	#gdc-4.6 -shared -o libtest.so -fPIC test.o -lc -nostartfiles
	dmd -g -c test.d -fPIC
	ld -shared -o libtest.so test.o -lrt -lphobos2 -lpthread
	gcc -g main.c -ldl -lpthread
	./a.out
clean:
	rm -rf *.so *.o *.out

With this setup I get

   ./libtest.so: undefined symbol: _deh_beg

With a fake main method added I get

   make: *** [test] Segmentation fault

This is what I get from gdb

   Program received signal SIGSEGV, Segmentation fault.
   0xb7fd1ed3 in std.stdio.__T7writelnTAyaZ.writeln() 
(_param_0=...) at   /usr/include/d/dmd/phobos/std/stdio.d:1550
   1550	    enforce(fprintf(.stdout.p.handle, "%.*s\n",

Event with the following startup hooks

extern(C) {

   void gc_init();
   void gc_term();

   void _init() {
     gc_init();
   }

   void _fini() {
     gc_term();
   }

}

I get the same error. I am using dmd 2.058 on Ubuntu 11.10 (32 
bit)

With gdc I get different errors, but it seems even more difficult 
to get it working.

Does anyone know what is missing to get proper shared library 
support working on Linux?
Apr 08 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-08 10:45, "Timo Westkämper" <timo.westkamper gmail.com>" wrote:

 I am still testing which setup gives me reliable shared D libraries
 which can be used from C.

 Here is my latest test:

 * test.d:
 import std.stdio;
 extern (C) {
 void hiD() {
 writeln("hi from D lib");
 }
 }

 * main.c
 #include <stdio.h>
 #include <dlfcn.h>
 #include <stdlib.h>
 void main() {
 void (*hiD)(void);
 void* handle = dlopen("./libtest.so", RTLD_LAZY);
 if (handle == NULL) {
 printf("%s\n", dlerror());
 exit(1);
 }
 hiD = dlsym(handle, "hiD");
 if (hiD != NULL) {
 hiD();
 } else {
 printf("hiD is null\n");
 }
 dlclose(handle);
 }

 * Makefile

 test:
 #gdc-4.6 -g -c test.d -fPIC -o test.o
 #gdc-4.6 -shared -o libtest.so -fPIC test.o -lc -nostartfiles
 dmd -g -c test.d -fPIC
 ld -shared -o libtest.so test.o -lrt -lphobos2 -lpthread
 gcc -g main.c -ldl -lpthread
 ./a.out
 clean:
 rm -rf *.so *.o *.out

 With this setup I get

 ./libtest.so: undefined symbol: _deh_beg

 With a fake main method added I get

 make: *** [test] Segmentation fault

 This is what I get from gdb

 Program received signal SIGSEGV, Segmentation fault.
 0xb7fd1ed3 in std.stdio.__T7writelnTAyaZ.writeln() (_param_0=...) at
 /usr/include/d/dmd/phobos/std/stdio.d:1550
 1550 enforce(fprintf(.stdout.p.handle, "%.*s\n",

 Event with the following startup hooks

 extern(C) {

 void gc_init();
 void gc_term();

 void _init() {
 gc_init();
 }

 void _fini() {
 gc_term();
 }

 }

 I get the same error. I am using dmd 2.058 on Ubuntu 11.10 (32 bit)

 With gdc I get different errors, but it seems even more difficult to get
 it working.

 Does anyone know what is missing to get proper shared library support
 working on Linux?


This is what I can think of for now:

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

-- 
/Jacob Carlborg
Apr 08 2012
parent reply mta`chrono <chrono mta-international.net> writes:
I'm interessting in the same stuff. I've a question to _tlsend and
_tlsstart. What are they used for? My disputable presumption was that
they point to the begin of TLS segment.


What is _deh_begin and _deh_end used for?
Apr 08 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-08 17:53, mta`chrono wrote:

 I'm interessting in the same stuff. I've a question to _tlsend and
 _tlsstart. What are they used for? My disputable presumption was that
 they point to the begin of TLS segment.


Yes, exactly, the start and end of the TLS segment.


 What is _deh_begin and _deh_end used for?


That would be start and end of the segment containing the exception 
handling tables.

-- 
/Jacob Carlborg
Apr 08 2012
prev sibling next sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/08/2012 03:45 AM, "Timo Westkämper" <timo.westkamper gmail.com>" 
wrote:

 extern(C) {

 void gc_init();
 void gc_term();

 void _init() {
 gc_init();
 }

 void _fini() {
 gc_term();
 }

 }


I think you want rt_init and rt_term here.
Apr 08 2012
parent reply "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
On Sunday, 8 April 2012 at 14:52:55 UTC, Ellery Newcomer wrote:

 On 04/08/2012 03:45 AM, "Timo Westkämper" 
 <timo.westkamper gmail.com>" wrote:

 extern(C) {

 void gc_init();
 void gc_term();

 void _init() {
 gc_init();
 }

 void _fini() {
 gc_term();
 }

 }


 I think you want rt_init and rt_term here.


I got now the simple example working:

* Makefile:

test:
	dmd -lib -g -c test.d -fPIC
	ld -shared -o libtest.so test.a -lrt -lphobos2 -lpthread
	gcc -g main.c -ldl -lpthread
	./a.out
clean:
	rm -rf *.a *.so *.o *.out

* test.d:
import std.stdio;
extern (C) void hiD() {
   writeln("hi from D lib");
}

Compiling as lib did the track and added the missing parts.

I will now advance with more complex examples.
Apr 08 2012
parent reply "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
Does someone know why the lib (.a) packaging instead of objects 
(.o) works better in this case?
Apr 08 2012
parent reply "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
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.
Apr 08 2012
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
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 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.
Apr 09 2012
parent reply "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
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 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", progbits
     .align 4
     .type   _tlsstart,  object
     .size   _tlsstart, 4
_tlsstart:
     .long   3

.globl _tlsend
     .section .tcommon,"awT", nobits
     .align 4
     .type   _tlsend,  object
     .size   _tlsend, 4
_tlsend:
     .zero   4

#endif


I will see if I can copy the exception handling parts from the D 
main wrapping code.

As a temporary solution I did this

extern(C) void _deh_beg() { }
extern(C) void _deh_end() { }
Apr 09 2012
parent reply Iain Buclaw <ibuclaw ubuntu.com> writes:
On 9 April 2012 20:37,  <"Timo Westk=E4mper\"
<timo.westkamper 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 gotte=




n

 it to compile working shared libs in the past.

 On 04/09/2012 01:24 AM, "Timo Westk=E4mper" <timo.westkamper gmail.com>"
 wrote:

 On Sunday, 8 April 2012 at 17:59:28 UTC, Timo Westk=E4mper 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 stora=


ge

 for
 =A0* thread-local data in D 2.0. =A0Both of these rely on the default lin=


ker

 script
 =A0* of:
 =A0* =A0 =A0 =A0.tdata : { *(.tdata .tdata.* .gnu.linkonce.td.*) }
 =A0* =A0 =A0 =A0.tbss =A0: { *(.tbss .tbss.* .gnu.linkonce.tb.*) *(.tcomm=


on) }

 =A0* to group the sections in that order.
 =A0*
 =A0* Sadly, this does not work because ld orders .tdata after .tdata.*,
 despite
 =A0* what the linker script says.
 =A0*/

 .file "tls.S"

 .globl _tlsstart
 =A0 =A0.section .tdata,"awT", progbits
 =A0 =A0.align 4
 =A0 =A0.type =A0 _tlsstart,  object
 =A0 =A0.size =A0 _tlsstart, 4
 _tlsstart:
 =A0 =A0.long =A0 3

 .globl _tlsend
 =A0 =A0.section .tcommon,"awT", nobits
 =A0 =A0.align 4
 =A0 =A0.type =A0 _tlsend,  object
 =A0 =A0.size =A0 _tlsend, 4
 _tlsend:
 =A0 =A0.zero =A0 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.

--=20
Iain Buclaw

*(p < e ? p++ : p) =3D (c & 0x0f) + '0';
Apr 09 2012
next sibling parent reply "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
On Monday, 9 April 2012 at 19:59:18 UTC, Iain Buclaw wrote:

 On 9 April 2012 20:37,  <"Timo Westkämper\"
 <timo.westkamper 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 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", progbits
    .align 4
    .type   _tlsstart,  object
    .size   _tlsstart, 4
 _tlsstart:
    .long   3

 .globl _tlsend
    .section .tcommon,"awT", 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
Apr 09 2012
next sibling parent "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
On Monday, 9 April 2012 at 20:31:44 UTC, Timo Westkämper wrote:

 On Monday, 9 April 2012 at 19:59:18 UTC, Iain Buclaw wrote:

 On 9 April 2012 20:37,  <"Timo Westkämper\"
 <timo.westkamper 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 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", progbits
    .align 4
    .type   _tlsstart,  object
    .size   _tlsstart, 4
 _tlsstart:
    .long   3

 .globl _tlsend
    .section .tcommon,"awT", 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


I just figured out this alternative approach which works as well:

import std.stdio;

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

// 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() {}


The declaration of the main method adds the tls and deh parts.
Apr 09 2012
prev sibling parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/09/2012 03:31 PM, "Timo Westkämper" <timo.westkamper gmail.com>" 
wrote:

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


what's wrong with them? if it is a link problem, use gcc -nostartfiles.
Well, I'm doing that, and it compiles and rt_init is called, but doesn't 
seem to be calling the module constructors, so maybe that is a very bad 
idea.
Apr 09 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-09 23:58, Ellery Newcomer wrote:

 On 04/09/2012 03:31 PM, "Timo Westkämper" <timo.westkamper gmail.com>"
 wrote:

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


 what's wrong with them? if it is a link problem, use gcc -nostartfiles.
 Well, I'm doing that, and it compiles and rt_init is called, but doesn't
 seem to be calling the module constructors, so maybe that is a very bad
 idea.


The module info (contains the module constructors) need to be setup 
differently when linking as a shared library.

-- 
/Jacob Carlborg
Apr 09 2012
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/10/2012 01:31 AM, Jacob Carlborg wrote:

 The module info (contains the module constructors) need to be setup
 differently when linking as a shared library.


The odd thing is, when you skip _init and _fini and just do

rt_init();
writeln("stuff");
rt_term();

it doesn't segfault
Apr 10 2012
next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-10 16:21, Ellery Newcomer wrote:

 On 04/10/2012 01:31 AM, Jacob Carlborg wrote:

 The module info (contains the module constructors) need to be setup
 differently when linking as a shared library.


 The odd thing is, when you skip _init and _fini and just do

 rt_init();
 writeln("stuff");
 rt_term();

 it doesn't segfault


Are the module constructors run?

-- 
/Jacob Carlborg
Apr 10 2012
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/10/2012 12:04 PM, Jacob Carlborg wrote:


 The odd thing is, when you skip _init and _fini and just do

 rt_init();
 writeln("stuff");
 rt_term();

 it doesn't segfault


 Are the module constructors run?


they would have to be for writeln to not segfault
Apr 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-10 19:12, Ellery Newcomer wrote:


 they would have to be for writeln to not segfault


Ok, I see.

-- 
/Jacob Carlborg
Apr 10 2012
parent reply Ellery Newcomer <ellery-newcomer utulsa.edu> writes:
On 04/10/2012 12:21 PM, Jacob Carlborg wrote:

 On 2012-04-10 19:12, Ellery Newcomer wrote:


 they would have to be for writeln to not segfault


 Ok, I see.


tried using __attribute__((constructor)) instead of _init.

If I'm getting this line to fail in rt.minfo.sortCtorsImpl:

                     /* Internal runtime error, dependency on an 
uninitialized
                      * module outside of the current module group.
                      */
                     (stackidx < modules.length) || assert(0);

would that be the problem you were referring to above?
Apr 10 2012
parent reply Jacob Carlborg <doob me.com> writes:
On 2012-04-10 21:28, Ellery Newcomer wrote:


 tried using __attribute__((constructor)) instead of _init.

 If I'm getting this line to fail in rt.minfo.sortCtorsImpl:

 /* Internal runtime error, dependency on an uninitialized
 * module outside of the current module group.
 */
 (stackidx < modules.length) || assert(0);

 would that be the problem you were referring to above?


Might be. It was a while since I last tried to build shared libraries 
with D. It was before the minfo module was created.

-- 
/Jacob Carlborg
Apr 10 2012
parent reply "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
On Tuesday, 10 April 2012 at 20:02:16 UTC, Jacob Carlborg wrote:

 On 2012-04-10 21:28, Ellery Newcomer wrote:


 tried using __attribute__((constructor)) instead of _init.

 If I'm getting this line to fail in rt.minfo.sortCtorsImpl:

 /* Internal runtime error, dependency on an uninitialized
 * module outside of the current module group.
 */
 (stackidx < modules.length) || assert(0);

 would that be the problem you were referring to above?


 Might be. It was a while since I last tried to build shared 
 libraries with D. It was before the minfo module was created.


This might be related: 
https://github.com/D-Programming-Language/druntime/pull/114
Apr 10 2012
parent Jacob Carlborg <doob me.com> writes:
On 2012-04-10 22:10, "Timo Westkämper" <timo.westkamper gmail.com>" wrote:


 This might be related:
 https://github.com/D-Programming-Language/druntime/pull/114


I think something like this needs to be added to have shared libraries 
properly work:

https://github.com/dawgfoto/druntime/blob/SharedRuntime/src/rt/dso.d

-- 
/Jacob Carlborg
Apr 11 2012
prev sibling parent "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
On Tuesday, 10 April 2012 at 14:21:28 UTC, Ellery Newcomer wrote:

 On 04/10/2012 01:31 AM, Jacob Carlborg wrote:

 The module info (contains the module constructors) need to be 
 setup
 differently when linking as a shared library.


 The odd thing is, when you skip _init and _fini and just do

 rt_init();
 writeln("stuff");
 rt_term();

 it doesn't segfault


Yes, I experienced the same.
Apr 10 2012
prev sibling parent Jacob Carlborg <doob me.com> writes:
On 2012-04-09 21:59, Iain Buclaw wrote:


 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.


Martin Nowak was/is working on shared library support in druntime, if I 
recall correctly.

-- 
/Jacob Carlborg
Apr 09 2012
prev sibling next sibling parent reply "Martin Nowak" <dawg dawgfoto.de> writes:
 With gdc I get different errors, but it seems even more difficult to get  
 it working.

 Does anyone know what is missing to get proper shared library support  
 working on Linux?


Most prerequisites are merged now but there are still some smaller things  
I need to do.

https://github.com/dawgfoto/dmd/tree/SharedRuntime
  - split off EH changes (github.com/D-Programming-Language/dmd/pull/821)

https://github.com/dawgfoto/druntime/tree/SharedRuntime
  - split off EH changes  
(github.com/D-Programming-Language/druntime/pull/185)
  - TLS ranges must not be updated in SIGUSR1
  - integrate dylib_fixes.c (weak main, automatic rt_init/rt_term)
  - integrate shared library tests
  - cleaner makefile and unittests

https://github.com/dawgfoto/phobos/tree/SharedRuntime
  - cleaner makefile and unittests

This should be all to support link-time shared libraries.

For runtime loading we'd need:

  - a GC hook to mark/finalize auxiliary memory
  - traversal of DSO dependency DAGs for thread
    local initialization
Apr 14 2012
parent "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> writes:
On Saturday, 14 April 2012 at 14:48:47 UTC, Martin Nowak wrote:

 With gdc I get different errors, but it seems even more 
 difficult to get it working.

 Does anyone know what is missing to get proper shared library 
 support working on Linux?


 Most prerequisites are merged now but there are still some 
 smaller things I need to do.

 https://github.com/dawgfoto/dmd/tree/SharedRuntime
  - split off EH changes 
 (github.com/D-Programming-Language/dmd/pull/821)

 https://github.com/dawgfoto/druntime/tree/SharedRuntime
  - split off EH changes 
 (github.com/D-Programming-Language/druntime/pull/185)
  - TLS ranges must not be updated in SIGUSR1
  - integrate dylib_fixes.c (weak main, automatic 
 rt_init/rt_term)
  - integrate shared library tests
  - cleaner makefile and unittests

 https://github.com/dawgfoto/phobos/tree/SharedRuntime
  - cleaner makefile and unittests

 This should be all to support link-time shared libraries.

 For runtime loading we'd need:

  - a GC hook to mark/finalize auxiliary memory
  - traversal of DSO dependency DAGs for thread
    local initialization


Ok. Good to know. Is there a ticket where I can follow the 
progress?

I opened this one, but there might be also another ticket for it 
: http://d.puremagic.com/issues/show_bug.cgi?id=7870
Apr 14 2012
prev sibling parent "GreatEmerald" <pastas4 gmail.com> writes:
On Sunday, 8 April 2012 at 08:45:46 UTC, Timo Westkämper wrote:

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


Hmm, wouldn't using DMD directly for the first two compilation 
steps do the same thing, just faster and simpler? Like this:

     dmd -shared -fPIC test.d

Although in my tests, it always gives me an error like this, no 
matter which way I try to compile it:

     ld: /usr/lib64/libphobos2.a(lifetime_368_548.o): relocation 
R_X86_64_32 against `_D15TypeInfo_Shared7__ClassZ' can not be 
used when making a shared object; recompile with -fPIC
     /usr/lib64/libphobos2.a: could not read symbols: Bad value

Though this is still with DMD v2.058, so perhaps there were some 
changes with this in the latest version. Or I'm missing something.

By the way, what is the status of D shared libraries on Windows?
Apr 14 2012