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
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
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.
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
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
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:
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
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,
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 06:40:56 UTC, ponce wrote:
On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:
I was trying to solve this one myself, but the modifications
to DMD's backend that are needed are out of reach for me right
now.
If you're willing to build your own
On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:
I was trying to solve this one myself, but the modifications to
DMD's backend that are needed are out of reach for me right now.
If you're willing to build your own druntime, you may be able
to get by.
I'd prefer a solution
On 9/16/2015 11:40 PM, ponce wrote:
On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:
I was trying to solve this one myself, but the modifications to DMD's backend
that are needed are out of reach for me right now.
If you're willing to build your own druntime, you may be able to
On Thursday, 17 September 2015 at 10:12:57 UTC, Walter Bright
wrote:
On 9/16/2015 11:40 PM, ponce wrote:
On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise wrote:
I was trying to solve this one myself, but the modifications
to DMD's backend
that are needed are out of reach for me
On Thursday, 17 September 2015 at 15:12:43 UTC, Jacob Carlborg
wrote:
On 2015-09-17 00:29, ponce wrote:
[...]
Easiest would be to not unload the library. If that doesn't
work, replace "_dyld_register_func_for_add_image" [1] with
"dyld_register_image_state_change_handler" [2].
[1]
On Thursday, 17 September 2015 at 15:12:43 UTC, Jacob Carlborg
wrote:
Easiest would be to not unload the library.
I don't control what the host program does.
If that doesn't work, replace
"_dyld_register_func_for_add_image" [1] with
"dyld_register_image_state_change_handler" [2].
[1]
On 2015-09-17 00:29, ponce wrote:
Context: On OSX, a C program can load a D shared library but once
unloaded the next dlopen will crash, jumping into a callback that
doesn't exist anymore.
I've filed it here: https://issues.dlang.org/show_bug.cgi?id=15060
It looks like this was known and
On Thursday, 17 September 2015 at 16:17:11 UTC, bitwise wrote:
On Thursday, 17 September 2015 at 10:12:57 UTC, Walter Bright
wrote:
On 9/16/2015 11:40 PM, ponce wrote:
On Wednesday, 16 September 2015 at 23:24:29 UTC, bitwise
wrote:
I was trying to solve this one myself, but the modifications
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
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 completelymeaning, either don't even
distribute a static druntime for OSX, or make shared druntime
the default. This way, druntime would only ever
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
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
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
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 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
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
Context: On OSX, a C program can load a D shared library but once
unloaded the next dlopen will crash, jumping into a callback that
doesn't exist anymore.
I've filed it here: https://issues.dlang.org/show_bug.cgi?id=15060
It looks like this was known and discussed several times already:
On Wednesday, 16 September 2015 at 22:29:46 UTC, ponce wrote:
Context: On OSX, a C program can load a D shared library but
once unloaded the next dlopen will crash, jumping into a
callback that doesn't exist anymore.
I've filed it here:
https://issues.dlang.org/show_bug.cgi?id=15060
It
27 matches
Mail list logo
