shared libs for OSX

[bitwise via Digitalmars-d]

On Tue, 26 May 2015 02:28:14 -0400, Jacob Carlborg <doob at me.com> wrote:

> On 2015-05-25 22:58, Martin Nowak wrote:
>> On Monday, 25 May 2015 at 19:40:52 UTC, bitwise wrote:
>>> 1) _dyld_register_func_for_add_image should be taken care of with the
>>> above two fixes
>>
>> You still cannot unregister the callback, so it can't be used for
>> dynamically loading druntime. Last time we talked about this problem, we
>> found some undocumented function that could be deregistered.
>>
>>> 2) __attribute__((constructor/destructor)) can be added to druntime
>>> when building for osx like in the file dylib_fixes.c [1]
>>
>> For linux we let the compiler emit comdat constructors into every D
>> object, so you'll end up with exactly a single function for any binary
>> containing D code.
>> I don't think you need ctors/dtors on OSX if you already have the dylib
>> callback.
>
> I'm not sure if there is any other solution. There is one private  
> function, "dyld_register_image_state_change_handler", that should work.  
> I think it works because the image is never unloaded. I have not seen  
> any function for deregistering a callback, private or public.
The

I think Martin is right. We don't need ctors/dtors or any compiler  
fanciness. All we need is the two callbacks, which can be registered when  
druntime is initialized.

_dyld_register_func_for_add_image
_dyld_register_func_for_remove_image

At this point, we would only be registering the callbacks once in the main  
image, and not from the shared library. Since all global functions and  
symbols are shared between images anyways, receiving the callback in the  
main image would be fine. So in this case, unregistering the callbacks is  
no longer needed.

> Isn't it better to avoid private undocumented functions?
Not only better, but mandatory, otherwise Apple will reject the app from  
the app store.
I am certain this is the case for iOS, and I assume it would be the same  
for desktop.

On Tue, 26 May 2015 02:30:51 -0400, Jacob Carlborg <doob at me.com> wrote:
>
> What do you plan to do about TLS?

How would loading shared libraries change this? Couldn't TLS, however it's  
implemented now, be applied to shared libraries as well?

   Bit