Posix dynamic library initialization and finalization

[Jacob Carlborg via Digitalmars-d]

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