digitalmars.D - Posix dynamic library initialization and finalization
- Adam D. Ruppe (30/30) Dec 12 2014 I was just talking on IRC with someone about a dynamic library on
- Paul O'Neil (6/48) Dec 12 2014 Is there a problem with calling rt_init multiple times from multiple
- Jacob Carlborg (22/49) Dec 13 2014 That file is the remains of my try to get dynamic libraries working on
I was just talking on IRC with someone about a dynamic library on linux in D being called from a C program. The runtime wasn't initialized and he couldn't modify the C program to add an extra call. I kidna thought rt_init would be done automatically in a constructor segment in the library, but it isn't. Interesting, there is a solution in the druntime source tree... but it isn't compiled in. found in this thread http://forum.dlang.org/thread/knk5ql$2np2$1 digitalmars.com this is the file: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.c And I tried it on Linux - compile that separately, then link in the object file in the D program - and everything was beautiful and perfect and there was much happy singing. Why isn't that dylib_fixes file used anywhere in the druntime makefiles? I guess one difficulty would be you don't want it called in a regular program.... but actually, is that bad? I think they just bump up a refcount if called twice, so that's no big deal, or even dmain could be changed not to call them, instead opting for the loader's magic. Alternatively, the compiler could insert the magic sections when compiling with -shared and leave it the way it is for the others. Is there a problem with that if it was a D program loading the D library? Another thing we could do is provide a way to access those magic attributes from D - pragma(elf_constructor) maybe - and then provide like a library mixin like we're doing for Windows DLLMain now - and document it so te users can find it. In any case, documenting that existing dylib_fixes.c would be nice if it is a good solution. It seems to be to me though!
Dec 12 2014
Paul O'Neil <redballoon36 gmail.com> On 12/12/2014 07:38 PM, Adam D. Ruppe wrote:I was just talking on IRC with someone about a dynamic library on linux in D being called from a C program. The runtime wasn't initialized and he couldn't modify the C program to add an extra call. I kidna thought rt_init would be done automatically in a constructor segment in the library, but it isn't. Interesting, there is a solution in the druntime source tree... but it isn't compiled in. found in this thread http://forum.dlang.org/thread/knk5ql$2np2$1 digitalmars.com this is the file: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.c And I tried it on Linux - compile that separately, then link in the object file in the D program - and everything was beautiful and perfect and there was much happy singing. Why isn't that dylib_fixes file used anywhere in the druntime makefiles? I guess one difficulty would be you don't want it called in a regular program.... but actually, is that bad? I think they just bump up a refcount if called twice, so that's no big deal, or even dmain could be changed not to call them, instead opting for the loader's magic. Alternatively, the compiler could insert the magic sections when compiling with -shared and leave it the way it is for the others. Is there a problem with that if it was a D program loading the D library? Another thing we could do is provide a way to access those magic attributes from D - pragma(elf_constructor) maybe - and then provide like a library mixin like we're doing for Windows DLLMain now - and document it so te users can find it. In any case, documenting that existing dylib_fixes.c would be nice if it is a good solution. It seems to be to me though!Is there a problem with calling rt_init multiple times from multiple shared libraries? -- Paul O'Neil Github / IRC: todayman
Dec 12 2014
On 2014-12-13 01:38, Adam D. Ruppe wrote:I was just talking on IRC with someone about a dynamic library on linux in D being called from a C program. The runtime wasn't initialized and he couldn't modify the C program to add an extra call. I kidna thought rt_init would be done automatically in a constructor segment in the library, but it isn't. Interesting, there is a solution in the druntime source tree... but it isn't compiled in. found in this thread http://forum.dlang.org/thread/knk5ql$2np2$1 digitalmars.com this is the file: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dylib_fixes.cThat file is the remains of my try to get dynamic libraries working on OS X. It might even be from the D1 days, it's available in Tango as well.And I tried it on Linux - compile that separately, then link in the object file in the D program - and everything was beautiful and perfect and there was much happy singing. Why isn't that dylib_fixes file used anywhere in the druntime makefiles?If I recall correctly someone thought it would be too magical. If you use D library from a C application you want some control, or something like that.I guess one difficulty would be you don't want it called in a regular program.... but actually, is that bad? I think they just bump up a refcount if called twice, so that's no big deal, or even dmain could be changed not to call them, instead opting for the loader's magic.I just had a look at the implementation of rt_init, it has a comment that says: "Need to synchronize rt_init/rt_term calls for version (Shared) druntime, because multiple C threads might initialize different D libraries without knowing about the shared druntime. Also we need to attach any thread that calls rt_init." [1]Alternatively, the compiler could insert the magic sections when compiling with -shared and leave it the way it is for the others. Is there a problem with that if it was a D program loading the D library?I don't think so, it has a guard for initializing the runtime multiple times [2].Another thing we could do is provide a way to access those magic attributes from D - pragma(elf_constructor) maybe - and then provide like a library mixin like we're doing for Windows DLLMain now - and document it so te users can find it. In any case, documenting that existing dylib_fixes.c would be nice if it is a good solution. It seems to be to me though!Yes, perhaps in the "Interfacing with C" section. Martin Nowak should know more about all this. [1] https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L152-L158 [2] https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L159 -- /Jacob Carlborg
Dec 13 2014