On 28 September 2013 18:39, Jacob Carlborg <doob@me.com> wrote:
> On 2013-09-28 18:48, Dicebot wrote:
>
>>  From my point of view two things that are necessary for making this
>> release:
>>
>> 1) working dynamic loading of shared libraries (what is the state of
>> this?)
>
>
> I would like to add: only on Linux.
>

I am fine with pushing that feature as an entirely new release (eg. 2.065).  What I'm concerned about are that we've had 4 months of adding *other* features, bug fixing, and other changes in the D frontend that need to be sync'd up.

Point two, shared library support in D is not transferable to gdc/ldc - so it's not even a beneficial feature in my eyes.

-- 
Iain Buclaw

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

On Saturday, 28 September 2013 at 18:32:51 UTC, Iain Buclaw wrote:
> I am fine with pushing that feature as an entirely new release (eg.
> 2.065).  What I'm concerned about are that we've had 4 months of
> adding *other* features, bug fixing, and other changes in the D
> frontend that need to be sync'd up.

I agree that it at least makes sense to make release branch to start slowly working towards fixing regressions and stabilizing stuff.

> Point two, shared library support in D is not transferable to gdc/ldc
> - so it's not even a beneficial feature in my eyes.

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?

On 28 September 2013 20:37, Dicebot <public@dicebot.lv> wrote:
> On Saturday, 28 September 2013 at 18:32:51 UTC, Iain Buclaw wrote:
>>
>> I am fine with pushing that feature as an entirely new release (eg. 2.065).  What I'm concerned about are that we've had 4 months of adding *other* features, bug fixing, and other changes in the D frontend that need to be sync'd up.
>
>
> I agree that it at least makes sense to make release branch to start slowly working towards fixing regressions and stabilizing stuff.
>
>
>> Point two, shared library support in D is not transferable to gdc/ldc - so it's not even a beneficial feature in my eyes.
>
>
> 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?

-- 
Iain Buclaw

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

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.

On 28 September 2013 21:02, Dicebot <public@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).  ;-)

-- 
Iain Buclaw

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

On 2013-09-28 21:37, Dicebot 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?

It's the usual issues, which have been mentioned many times before:

* Exception handling tables
* TLS data
* GC roots
* Module infos
* Basically anything the runtime needs to collect from the running executable/shared library.

I don't know the status of these.

-- 
/Jacob Carlborg

On Saturday, 28 September 2013 at 20:17:24 UTC, Iain Buclaw wrote:
> On 28 September 2013 21:02, Dicebot <public@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.

On Sunday, 29 September 2013 at 09:23:16 UTC, Jacob Carlborg wrote:
> It's the usual issues, which have been mentioned many times before:
>
> * Exception handling tables
> * TLS data
> * GC roots
> * Module infos
> * Basically anything the runtime needs to collect from the running executable/shared library.
>
> I don't know the status of these.

Yeah, I am mostly familiar with those but though this is exactly what is ongoing shared lib support is about - to make this possible. Right now on master it does seem to work only for D lib + D app and C lib + D app though :(

On Sep 29, 2013 10:45 AM, "Dicebot" <public@dicebot.lv> wrote:
>
> On Saturday, 28 September 2013 at 20:17:24 UTC, Iain Buclaw wrote:
>>
>> On 28 September 2013 21:02, Dicebot <public@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';

On 2013-09-29 12:25, Iain Buclaw wrote:

> - 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.

How is exception handling tables, module infos, GC range and TLS data handled now in GDC?

I guess we should change druntime to use "dl_iterate_phdr" on Linux and FreeBSD instead of these bracketed segments. Or is there some better way?

Mac OS X already uses "getsectbynamefromheader" and similar functions to avoid bracketed segments.

-- 
/Jacob Carlborg