On Sep 29, 2013 10:45 AM, "Dicebot" <pub...@dicebot.lv> wrote:
>
> On Saturday, 28 September 2013 at 20:17:24 UTC, Iain Buclaw wrote:
>>
>> On 28 September 2013 21:02, Dicebot <pub...@dicebot.lv> wrote:
>>>
>>> On Saturday, 28 September 2013 at 19:53:16 UTC, Iain Buclaw wrote:
>>>>>
>>>>>
>>>>> I thought it is a temporary limitation (I am very interested in
loading D
>>>>> plugins from C/C++ programs). Are there any fundamental issues that
>>>>> prevent
>>>>> it?
>>>>
>>>>
>>>>
>>>> In gdc or dmd?
>>>
>>>
>>>
>>> Both. g++ / dmd and g++ / gdc.
>>
>>
>> There's no limitations really loading C/C++ libraries into D - don't
>> know about dmd...
>>
>> Thought you meant fundamental issues that prevent shared library
>> support in dmd/gdc (as in D libraries).  ;-)
>
>
> No, not loading C plugins from D, other way around ;)
> I have tried it right now on dmd master + gcc 4.8.1 and shared library
was rejected to be loaded because of TLS. Was curious if this is
fundamental limitation or eventually can be worked around.

Run time support for shared libraries in gdc is non existent compared to
incomplete, as all of Martin's patches have not been pulled in. And at this
rate they never will, so will be forced to fork eventually (what I
currently do is more like a spork), but hey I guess that's the point of
druntime, no?  Each compiler has its own version that is incompatible with
the next compiler.  No one cares about ABI compatibility anyway... *grin*

Reasons I won't be going down the route of dmd's implementation is because.

- Relies on some undocumented implementation detail of how symbols are
written to object file by the compiler.

- Not sure if possible to express the same in gdc; bearing in mind we emit
assembly, not object code.

- Though I can't be sure because I don't know what it is actually doing
other than creating some custom bracketed segment (Really??? Is this truly
necessary? That's about as useful as having a separate calling convention
just for one language.  Oh wait!!!)  However, see point one on why there is
uncertainty surrounding this.

Not following dmd's way of doing things is nothing new however...

Regards
-- 
Iain Buclaw

*(p < e ? p++ : p) = (c & 0x0f) + '0';

Reply via email to