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/[email protected]
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!
