[phobos] Showstopper bug: Hello world fails on OSX!

[Sean Kelly]

On Nov 10, 2010, at 1:55 AM, Jacob Carlborg wrote:

> I've been thinking about this and I'm trying to think of everything to get this right the first time so I have a couple of questions:
> 
> * I though it might be a good idea to add support for running module constructors for dynamically loaded libraries (i.e. libraries loaded with dlopen). Then I was think I need to add the new module infos to the array of existing ones and when/if the library is unloaded remove the module infos added by the library. Now for the question: is an array still a good data structure for this or should we use an associative array or something else?

The real tricky part is adding the new TLS data to running threads.  It might be necessary to call thread_suspendAll() and then some new routine to graft the TLS data in place.  And things get even worse if dlclose is called.

> * If we change to an associative array could the image received in the callback function registered by _dyld_register_func_for_add_image be used as the key in the associative array?

Seems like that should work, since the address will be globally unique... unless dlclose is called, the data is retained, and then dlopen called on a new library.

> * This is a question about the _dyld_register_func_for_add_image function. Can I assume that all images sent to the registered callback functions are of the same architecture that I'm currently compiling? For example, I'm running a universal binary and it's running the 32bit part of the binary. Then I'm loading a universal dynamic library, it will only load the 32bit part since that's the part I'm running?

I think that's a reasonable assumption.

> * What to name the function, where to put it and when to call it?

Probably src/rt/memory_osx.c.  Give it a name like _d_whatever and it can be changed later if needed.