Desperately looking for a work-around to load and unload D shared libraries from C on OSX

[bitwise via Digitalmars-d]

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 
>>>> 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 that works with existing compilers, but 
>>> maybe building a
>>> custom LDC is possible if I figure it out.
>>
>> I seriously doubt this issue has anything to do with the 
>> compiler's code generator back end. It's more likely the 
>> problem is in druntime.
>
> Based on previous posts you've made, it seems you already know 
> that Martin's solution involves having DMD's back end add linux 
> style ctors/dtors to the COMDAT section of every compiled D 
> file, so I'm not sure what you mean by this.
>
> If a callback provided to _dyld_register_func_for_add_image 
> does not call sections_osx_onAddImage, then it must be called 
> somehow.
>
>    Bit

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