[D-runtime] Runtime issue on Mac OS X

[Brad Roberts]

C apps still must initialize the d runtime, so do it from rt_init() or 
whatever the function is called these days.

On Wed, 20 Jun 2012, Sean Kelly wrote:

> Date: Wed, 20 Jun 2012 22:16:48 -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
> 
> 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
> _______________________________________________
> D-runtime mailing list
> D-runtime at puremagic.com
> http://lists.puremagic.com/mailman/listinfo/d-runtime
>