digitalmars.D - Shared library in D on Linux
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (66/66) Apr 08 2012 I am still testing which setup gives me reliable shared D
- Jacob Carlborg (7/72) Apr 08 2012 This is what I can think of for now:
- mta`chrono (4/4) Apr 08 2012 I'm interessting in the same stuff. I've a question to _tlsend and
- Jacob Carlborg (6/10) Apr 08 2012 That would be start and end of the segment containing the exception
- Ellery Newcomer (3/13) Apr 08 2012 I think you want rt_init and rt_term here.
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (18/36) Apr 08 2012 I got now the simple example working:
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (2/2) Apr 08 2012 Does someone know why the lib (.a) packaging instead of objects
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (2/4) Apr 08 2012 Didn't work after all with -lib. I mixed up outputs.
- Ellery Newcomer (4/8) Apr 09 2012 Well, if you're really hankering for a shared lib, try ldc. I have
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (41/52) Apr 09 2012 Thanks, I might switch to ldc, if dmd and gdc fail here.
- Iain Buclaw (14/62) Apr 09 2012 n
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (40/118) Apr 09 2012 Ok. Good to know. Here is what I came up with for now.
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (15/135) Apr 09 2012 I just figured out this alternative approach which works as well:
- Ellery Newcomer (6/7) Apr 09 2012 what's wrong with them? if it is a link problem, use gcc -nostartfiles.
- Jacob Carlborg (5/15) Apr 09 2012 The module info (contains the module constructors) need to be setup
- Ellery Newcomer (6/8) Apr 10 2012 The odd thing is, when you skip _init and _fini and just do
- Jacob Carlborg (4/14) Apr 10 2012 Are the module constructors run?
- Ellery Newcomer (2/11) Apr 10 2012 they would have to be for writeln to not segfault
- Jacob Carlborg (4/5) Apr 10 2012 Ok, I see.
- Ellery Newcomer (9/12) Apr 10 2012 tried using __attribute__((constructor)) instead of _init.
- Jacob Carlborg (5/12) Apr 10 2012 Might be. It was a while since I last tried to build shared libraries
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (3/16) Apr 10 2012 This might be related:
- Jacob Carlborg (6/8) Apr 11 2012 I think something like this needs to be added to have shared libraries
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (2/13) Apr 10 2012 Yes, I experienced the same.
- Jacob Carlborg (5/9) Apr 09 2012 Martin Nowak was/is working on shared library support in druntime, if I
- Martin Nowak (18/22) Apr 14 2012 Most prerequisites are merged now but there are still some smaller thing...
- "Timo =?UTF-8?B?V2VzdGvDpG1wZXIi?= <timo.westkamper gmail.com> (5/31) Apr 14 2012 Ok. Good to know. Is there a ticket where I can follow the
- GreatEmerald (13/16) Apr 14 2012 Hmm, wouldn't using DMD directly for the first two compilation
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
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
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
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
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
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: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.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
Does someone know why the lib (.a) packaging instead of objects (.o) works better in this case?
Apr 08 2012
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
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
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: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() { }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
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:nWell, if you're really hankering for a shared lib, try ldc. I have gotte=?it to compile working shared libs in the past. On 04/09/2012 01:24 AM, "Timo Westk=E4mper" <timo.westkamper gmail.com>" wrote: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=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.#if linux /* The memory between the addresses of _tlsstart and _tlsend is the stora=gefor =A0* thread-local data in D 2.0. =A0Both of these rely on the default lin=kerscript =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 #endifThat 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
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: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 infoOn Monday, 9 April 2012 at 15:14:45 UTC, Ellery Newcomer 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.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: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 #endifOn 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
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: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.On 9 April 2012 20:37, <"Timo Westkämper\" <timo.westkamper gmail.com>" puremagic.com> wrote: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 infoOn Monday, 9 April 2012 at 15:14:45 UTC, Ellery Newcomer 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.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: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 #endifOn 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
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
On 2012-04-09 23:58, Ellery Newcomer wrote:On 04/09/2012 03:31 PM, "Timo Westkämper" <timo.westkamper gmail.com>" wrote:The module info (contains the module constructors) need to be setup differently when linking as a shared library. -- /Jacob CarlborgFor 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
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
On 2012-04-10 16:21, Ellery Newcomer wrote:On 04/10/2012 01:31 AM, Jacob Carlborg wrote:Are the module constructors run? -- /Jacob CarlborgThe 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
On 04/10/2012 12:04 PM, Jacob Carlborg wrote:they would have to be for writeln to not segfaultThe odd thing is, when you skip _init and _fini and just do rt_init(); writeln("stuff"); rt_term(); it doesn't segfaultAre the module constructors run?
Apr 10 2012
On 2012-04-10 19:12, Ellery Newcomer wrote:they would have to be for writeln to not segfaultOk, I see. -- /Jacob Carlborg
Apr 10 2012
On 04/10/2012 12:21 PM, Jacob Carlborg wrote:On 2012-04-10 19:12, 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?they would have to be for writeln to not segfaultOk, I see.
Apr 10 2012
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
On Tuesday, 10 April 2012 at 20:02:16 UTC, Jacob Carlborg wrote:On 2012-04-10 21:28, Ellery Newcomer wrote:This might be related: https://github.com/D-Programming-Language/druntime/pull/114tried 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.
Apr 10 2012
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/114I 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
On Tuesday, 10 April 2012 at 14:21:28 UTC, Ellery Newcomer wrote:On 04/10/2012 01:31 AM, Jacob Carlborg wrote:Yes, I experienced the same.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
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
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
On Saturday, 14 April 2012 at 14:48:47 UTC, Martin Nowak wrote: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=7870With 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
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 -lpthreadHmm, 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