shared libs for OSX

bitwise via Digitalmars-d digitalmars-d at puremagic.com
Thu May 21 18:13:56 PDT 2015


On Thu, 21 May 2015 15:34:56 -0400, Jacob Carlborg <doob at me.com> wrote:

> On 2015-05-21 10:12, Timothee Cour via Digitalmars-d wrote:
>> dlopen() of a D shared library works when called from a C++ file, and
>> that a C++ file can call multiple D shared libraries simultaneously when
>> using RTLD_LAZY option.
>>
>> Before waiting for a full solution with an integrated druntime, is there
>> at least a way to have a separate runtime in each shared library, so
>> that dlopen() can be called from a D file?
>
> No, not out of the box.
>
> I'm not sure if I remember all the details correctly, but this is  
> basically how it works:
>
> The runtime uses the "_dyld_register_func_for_add_image" function  
> provided by the dynamic linker. This function is used to register a  
> callback. The callback will be called for each currently loaded image  
> (executable/dynamic library) in the executable. The callback will also  
> be called for every newly loaded image, i.e. using dlopen. You need to  
> keep track of which image is yourself and which are other images you  
> should ignore.
>
> Then, the other problem with "_dyld_register_func_for_add_image" is that  
> it's not possible to unregister the callback. Which means, if you  
> register a callback using this function from a dynamic library loaded  
> with dlopen and then unload it. Next time dlopen is called it will  
> crash, because the callback points to an address that doesn't exist  
> anymore.
>
> There's an other, undocumented, function that does basically the same  
> but prevents the issue with the callback by not allowing the dynamic  
> library to be unloaded.

So does that mean that "_dyld_register_func_for_add_image" shouldn't be  
called at all from shared libs at all then? The fact that there is no  
"unregister" function seems to suggest that it's meant to be called once  
 from the main executable to add a callbacck that survives the entire life  
of the program. Can't whatever the callback does be done from the runtime  
linked to the main executable?

   Bit


More information about the Digitalmars-d mailing list