On 2015-09-18 11:43, ponce wrote:

> Much success.
> Not only did this work, it worked (around) right away!
>
> Final patch here:
> https://github.com/p0nce/dplug/commit/7dc6385ebb8147cc53cfe69bfd54e41f5341e158

The way it behaves is that the runtime uses a function to register the a callback which is called by the dynamic linker each time an image (dynamic library/exectuable) is loaded.

When the callback points to a function that itself is located in a dynamic library it will cause dlopen to crash if the dynamic library has been unloaded because the callback is not valid anymore.

For some reason it's not possible to unregister a callback.

When "dyld_register_image_state_change_handler" is used instead, it pins the dynamic library which contains the callback and it's actually never unloaded, even though dlclose is called.

So when dyld_register_image_state_change_handler is called from you're plugin it pins the dynamic library and the callback register in the runtime will still be valid.

-- 
/Jacob Carlborg

On Friday, 18 September 2015 at 09:43:43 UTC, ponce wrote:
> On Thursday, 17 September 2015 at 21:13:46 UTC, bitwise wrote:
>>     [...]
>
> 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.

Woot! Go team! =)

On 2015-09-18 16:53, bitwise wrote:

> Woot! Go team! =)

No, no, no. D team :D

-- 
/Jacob Carlborg

On Thursday, 17 September 2015 at 21:13:46 UTC, bitwise wrote:
> He can simply create a second empty callback in VSTPluginMain which will pin his library:

Yikes, pinning the library is really ugly hack around the actual issue.
Anyone has an idea how to use the crappy dyld API w/o crashing on unload?

If nothing helps we could try to add init/fini calls to binaries like we do w/ ELF.

On 2015-09-19 18:53, Martin Nowak wrote:

> Yikes, pinning the library is really ugly hack around the actual issue.
> Anyone has an idea how to use the crappy dyld API w/o crashing on unload?

I don't think it possible since there's no API to unregister the callback.

> If nothing helps we could try to add init/fini calls to binaries like we
> do w/ ELF.

I think this would be best choice. That's how the libSystem (the C standard library and a couple of other libraries) is initialized.

-- 
/Jacob Carlborg

On Saturday, 19 September 2015 at 16:53:28 UTC, Martin Nowak wrote:
> On Thursday, 17 September 2015 at 21:13:46 UTC, bitwise wrote:
>> He can simply create a second empty callback in VSTPluginMain which will pin his library:
>
> Yikes, pinning the library is really ugly hack around the actual issue.
> Anyone has an idea how to use the crappy dyld API w/o crashing on unload?
>
> If nothing helps we could try to add init/fini calls to binaries like we do w/ ELF.

I wanted to attempt this myself, but I think I'm going to throw in the towel...

I wunderstand the mach-o format ok, and was able to get druntime to build as a shared library, but after spending some time looking through DMD's backend... I find myself very discouraged by the code quality.

Not trying to be mean, but that code was clearly not written with teamwork in mind. With the vast majority of methods and variables being named things like "bytes" or "SDshtidx", I find myself all but completely helpless.

I understand why people keep complaining about the backend and trying to say it should be swapped out for llvm or something.

    Bit

On Thursday, 17 September 2015 at 21:13:46 UTC, bitwise wrote:
> The op shouldn't have to actually modify druntime in this case. He shouldn't have to replace "_dyld_register_func_for_add_image".

Now that you guys digged in the dyld implementation, did anyone find a solution to use the callback mechanism and still support unloading of libraries?
Pinning libraries is only a hacky workaround.

Let's please continue the discussion in Bugzilla.
https://issues.dlang.org/show_bug.cgi?id=15060#c4