On Thursday, 17 September 2015 at 16:42:52 UTC, bitwise wrote:
>
> One solution which could work is to disallow static linking of druntime on OSX completely....meaning, either don't even distribute a static druntime for OSX, or make shared druntime the default. This way, druntime would only ever be initialized once per process. Knowing this, linux ctors/dtors could be added to druntime to initialize it, eliminating the need to call rt_init/rt_term before and after main(). Also, if druntime were loaded into a C-hosted binary, druntime would automatically be initialized by the ctors/dtors. Also, for the ctors/dtors, they could be added to the druntime build, and wouldn't having to be compiler generated.
>
> I'm not sure about the difference in performance cost over static vs shared druntime, but it seems that this is the way things are done on OSX. If you look in /usr/lib/ on a mac, practically everything is a shared lib.
>
>     Bit

I use static linking of druntime already all the time and rely on it to be able to do something instead of nothing (where would I even found that shared druntime?). Apart from this one horrible bug, static runtime seems very much working. Remove possibilities to do work would make my situation worse.

I can call rt_init / rt_term at the right place with LDC global constructor/destructors no problem. The problem is this callback that cannot be removed. Don't know why it's there in the first place since by definition a shared library can't control when it's unloaded.

On Thursday, 17 September 2015 at 16:54:09 UTC, ponce wrote:
> On Thursday, 17 September 2015 at 16:42:52 UTC, bitwise wrote:
>>     [...]
>
> I use static linking of druntime already all the time and rely on it to be able to do something instead of nothing (where would I even found that shared druntime?). Apart from this one horrible bug, static runtime seems very much working. Remove possibilities to do work would make my situation worse.
>
> I can call rt_init / rt_term at the right place with LDC global constructor/destructors no problem. The problem is this callback that cannot be removed. Don't know why it's there in the first place since by definition a shared library can't control when it's unloaded.

It seems that you either haven't read, or did not understand my previous posts. This is a complicated problem, and unless you're willing to dig much deeper into it, then you'll have to deal with things the way they are.

   Bit

On 2015-09-17 18:20, bitwise wrote:

> dyld_register_image_state_change_handler does not provide a way to
> unregister the callback either, so I don't see how this helps.

The dynamic library holding the callback is pinned. See the implementation of registerImageStateSingleChangeHandler, the first few lines.

[1] http://www.opensource.apple.com/source/dyld/dyld-353.2.3/src/dyld.cpp

-- 
/Jacob Carlborg

On Thursday, 17 September 2015 at 19:20:34 UTC, Jacob Carlborg wrote:
> On 2015-09-17 18:20, bitwise wrote:
>
>> dyld_register_image_state_change_handler does not provide a way to
>> unregister the callback either, so I don't see how this helps.
>
> The dynamic library holding the callback is pinned. See the implementation of registerImageStateSingleChangeHandler, the first few lines.
>
> [1] http://www.opensource.apple.com/source/dyld/dyld-353.2.3/src/dyld.cpp

Ok, but this kinda defeats the purpose, as the op wants to unload the library ;)

    Bit

On 2015-09-17 21:42, bitwise wrote:

> Ok, but this kinda defeats the purpose, as the op wants to unload the
> library ;)

I'm not sure. Apparently he has no control of the host which will, most likely, unload regardless if he wants to or not.

-- 
/Jacob Carlborg

On 2015-09-17 21:42, bitwise wrote:

> Ok, but this kinda defeats the purpose, as the op wants to unload the
> library ;)

He said he doesn't want dlopen to crash, if it doesn't unload it fixes the problem ;)

-- 
/Jacob Carlborg

On Thursday, 17 September 2015 at 20:47:49 UTC, Jacob Carlborg wrote:
> On 2015-09-17 21:42, bitwise wrote:
>
>> Ok, but this kinda defeats the purpose, as the op wants to unload the
>> library ;)
>
> He said he doesn't want dlopen to crash, if it doesn't unload it fixes the problem ;)

True. Looking at his bug report now, it seems his dylib is a VST plugin. Had he just said that to begin with, this conversation would have been a lot easier -_-

The op shouldn't have to actually modify druntime in this case. He shouldn't have to replace "_dyld_register_func_for_add_image".

He can simply create a second empty callback in VSTPluginMain which will pin his library:

static bool didInitRuntime = false;

const char* ignoreImageLoad(
    enum dyld_image_states state,
    uint32_t infoCount,
    const struct dyld_image_info info[])
{
    // ignore.
}

extern(C) void* VSTPluginMain(void* hostCallback)
{
    import core.runtime;

    if(!didInitRuntime)
    {
        Runtime.initialize();
        dyld_register_image_state_change_handler(
            dyld_image_state_initialized,
            &ignoreImageLoad);
        didInitRuntime = true;
    }

    import std.stdio;
    import core.stdc.stdio;
    printf("Hello !\n");

    // Runtime.terminate();
    return null;
}

    Bit

On Thursday, 17 September 2015 at 20:47:49 UTC, Jacob Carlborg wrote:
> On 2015-09-17 21:42, bitwise wrote:
>
>> Ok, but this kinda defeats the purpose, as the op wants to unload the
>> library ;)
>
> He said he doesn't want dlopen to crash, if it doesn't unload it fixes the problem ;)

Yes, it would help.

On 2015-09-17 23:13, bitwise wrote:

> True. Looking at his bug report now, it seems his dylib is a VST plugin.
> Had he just said that to begin with, this conversation would have been a
> lot easier -_-
>
> The op shouldn't have to actually modify druntime in this case. He
> shouldn't have to replace "_dyld_register_func_for_add_image".
>
> He can simply create a second empty callback in VSTPluginMain which will
> pin his library

That's pretty clever, why didn't I think of that :)

-- 
/Jacob Carlborg

On Thursday, 17 September 2015 at 21:13:46 UTC, bitwise wrote:
> On Thursday, 17 September 2015 at 20:47:49 UTC, Jacob Carlborg wrote:
>> On 2015-09-17 21:42, bitwise wrote:
>>
>>> Ok, but this kinda defeats the purpose, as the op wants to unload the
>>> library ;)
>>
>> He said he doesn't want dlopen to crash, if it doesn't unload it fixes the problem ;)
>
> True. Looking at his bug report now, it seems his dylib is a VST plugin. Had he just said that to begin with, this conversation would have been a lot easier -_-
>
> The op shouldn't have to actually modify druntime in this case. He shouldn't have to replace "_dyld_register_func_for_add_image".
>
> He can simply create a second empty callback in VSTPluginMain which will pin his library:
>
> static bool didInitRuntime = false;
>
> const char* ignoreImageLoad(
>     enum dyld_image_states state,
>     uint32_t infoCount,
>     const struct dyld_image_info info[])
> {
>     // ignore.
> }
>
> extern(C) void* VSTPluginMain(void* hostCallback)
> {
>     import core.runtime;
>
>     if(!didInitRuntime)
>     {
>         Runtime.initialize();
>         dyld_register_image_state_change_handler(
>             dyld_image_state_initialized,
>             &ignoreImageLoad);
>         didInitRuntime = true;
>     }
>
>     import std.stdio;
>     import core.stdc.stdio;
>     printf("Hello !\n");
>
>     // Runtime.terminate();
>     return null;
> }
>
>     Bit

Much success.
Not only did this work, it worked (around) right away!

Final patch here:
https://github.com/p0nce/dplug/commit/7dc6385ebb8147cc53cfe69bfd54e41f5341e158

Thanks to you all and I will for sure include your name in the release notes.
You removed a huge roadblock on my path to being relevant.