On Jun 22, 2012, at 07:35 AM, Sean Kelly <sean@invisibleduck.org> wrote:

> On Jun 21, 2012, at 11:23 AM, Brad Roberts wrote:
>
> > C apps still must initialize the d runtime, so do it from rt_init() or whatever the function is called these days.
>
> Or the library could expose an init() call of its own that first calls rt_init(). Either way, I think this is different from requiring the app developer to provide a static address or whatever for the function map.

I don't think it's necessary to manually call "rt_init". I think the GCC extension __attribute__((constructor)) can be used for this.

--
/Jacob Carlborg

On Fri, 22 Jun 2012 23:10:52 +0200, Jacob Carlborg <doob@me.com> wrote:

>
>
> On Jun 22, 2012, at 07:35 AM, Sean Kelly <sean@invisibleduck.org> wrote:
>
>> On Jun 21, 2012, at 11:23 AM, Brad Roberts wrote:
>>
>> > C apps still must initialize the d runtime, so do it from rt_init() or
>> > whatever the function is called these days.
>>
>> Or the library could expose an init() call of its own that first calls rt_init(). Either way, I think this is different from requiring the app developer to provide a static address or whatever for the function map.
> I don't think it's necessary to manually call "rt_init". I think the GCC extension __attribute__((constructor)) can be used for this.
>
> --
> /Jacob Carlborg

That's probably not the best idea. One might prefer control over magic.
It also implies that we have to peek through all loaded C libraries to search
dependent D libraries which AFAIK is only feasible by hacking libc structures.
_______________________________________________
D-runtime mailing list
D-runtime@puremagic.com
http://lists.puremagic.com/mailman/listinfo/d-runtime