osx shared libraries.

[bitwise via Digitalmars-d]

On Sat, 06 Jun 2015 16:04:33 -0400, Walter Bright  
<newshound2 at digitalmars.com> wrote:

> On 6/6/2015 12:09 PM, bitwise wrote:
>> On Sat, 06 Jun 2015 14:52:11 -0400, bitwise <bitwise.pvt at gmail.com>  
>> wrote:
>>> Any ideas on this would be much appreciated.
>>>
>>> Thanks,
>>>    Bit
>>
>> One thought that just occurred to me would be to require that D dynamic
>> libraries contain a main entry point, like DllMain on Windows. This  
>> seems like
>> the only real/reliable option.
>>
>> The coder would have to explicitly give dmd a module in which to place  
>> the
>> constructor/destructor code for images, the same way that dmd adds a  
>> C-main in
>> the file where D-main is found. Enforcing this in the future would be a  
>> breaking
>> change, but not a dangerous one. It would be a simple link-time error  
>> which was
>> easy to fix.
>>
>> Also, requiring all D binaries to have some kind of entry point would  
>> alleviate
>> the need to ever call Runtime.initialize() explicitly.
>>
>>    Bit
>
> Martin Nowak is the author of most of the OSX DLL support, but he seems  
> to not be around lately.
>
> I'd rather have a dynamic library entry point than put a  
> constructor/destructor call into every object file.

Right. I was wondering what he was doing there...Just learned what COMDAT  
is ;)

It's starting to look like reworking druntime was the easy part. I've got  
druntime built as a shared library now, and my main project, which thus  
far is an app/graphics/game engine, is working nicely. Of course, all this  
goes out the window with a C-Host app... unless people knew to link the  
shared druntime with their C host app, which doesn't sound intuitive.

I like the idea of a dll entry point though.

I suppose it could look something like this:

enum Reason {
     processAttach,
     processDetach,
     threadAttach,
     threadDetatch
}

bool main(void *handle, Reason reason) {
     return true;
}

For windows, we could simply hijack DllMain().

As for the OSX, we could use an entry point stub like this, with the rest  
of the code in druntime:

// dladdr(&symbol) gets us the mach_image*
void _osx_image_init(void *symbol);
void _osx_image_term(void *symbol);

__attribute__((visibility("hidden"), constructor))
static void _image_init() {
     _osx_image_init((void*)&_image_init);
}
__attribute__((visibility("hidden"), destructor))
static void _image_term(){
     _osx_image_term((void*)&_image_term);
}

I would like to do the above stub in D, but I haven't found a way to  
specify visibility or section of the function yet.

I would rather not do what Martin has done, outputting the entire thing in  
asm, as that would take me a very long time to get right.

Anyways, onward!

Thanks
   Bit