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.c
That 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
