[D-runtime] Runtime issue on Mac OS X

[Sean Kelly]

This is great if the main app is D but harder (or at least more visible) if it's C. 

On Jun 20, 2012, at 9:47 PM, Brad Roberts <braddr at puremagic.com> wrote:

> The better fix is to register just one hook via the main app startup and 
> have subsequently opened libraries hook in via a druntime api that 
> maintains a list that can be removed from safely.
> 
> On Wed, 20 Jun 2012, Sean Kelly wrote:
> 
>> Date: Wed, 20 Jun 2012 17:02:18 -0700
>> From: Sean Kelly <sean at invisibleduck.org>
>> Reply-To: D's runtime library developers list <d-runtime at puremagic.com>
>> To: D's runtime library developers list <d-runtime at puremagic.com>
>> Subject: Re: [D-runtime] Runtime issue on Mac OS X
>> 
>> On Jun 20, 2012, at 1:53 PM, Jacob Carlborg wrote:
>> 
>>> 
>>> On 20 jun 2012, at 19:28, Sean Kelly wrote:
>>> 
>>>> A lot of work needs to be done to support dynamic libraries properly.  Thread lists need to be dynamically merged and unmerged, static segment info, ModuleInfo, etc.  We already have Runtime.load/unloadLibrary, so if we assume that D programmers will always call these instead of dlopen/dlclose directly then we just need to make sure the routines handle both C and D dynamic libraries appropriately.  Also, it should be possible to use the same D dynamic library with both C and D apps, which I guess means that Druntime would have to live in its own dynamic library as well.
>>> 
>>> 
>>> Yeah, I know. I know in theory what's need to be done (and I'm probably missing somethings here as well). But it's these particle things that cause problems, like _dyld_register_func_for_add_image probably can't be used.
>> 
>> It can't be used if a dynamic library calls this function and is then later unloaded via dlclose.  The easy way out would be to say that the result of calling dlclose on a Druntime dynamic library is undefined, and then put Druntime in its own dynamic library so random D dynamic libraries could be loaded and unloaded safely.  If you call dlopen for a library once, future dlopen calls will be effectively no-ops, right?
>> 
>> One not great alternative would be to provide a function that registers a trampoline function in the calling process.  I'd guess this would mean passing in the address of a static void* to hold this to rt_init() or something though.
>> 
>> It's weird that there's no unregister function.  Have you checked the darwin sources?
>> 
>> _______________________________________________
>> D-runtime mailing list
>> D-runtime at puremagic.com
>> http://lists.puremagic.com/mailman/listinfo/d-runtime
>> 
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime