January 10, 2013
On Thursday, 10 January 2013 at 14:07:38 UTC, Jacob Carlborg wrote:
> On 2013-01-10 11:31, evilrat wrote:
>
>> what's wrong with them? already used it on windows and mac, no problems
>> so far, though not tested too deep, and not with D shared libs o_O
>
> Apparently you haven't tested at all on Mac since it's only implemented on Windows:
>
> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L122

well like i said i don't used D shared libs yet.

umm.. looks simple at glance, whats the catch then if it still not implemented at least on osx?
January 10, 2013
I think the main issue is scanning static memory segments in the shared library during collections. Pretty sure this is sorted for Windows, but I think work still needs to be done for other platforms.  It's been a while since I've looked at this code though. Other things may be needed as well. Either way, if your D shared library is operating as if it were a C library then you should be fine. The trick is getting all shared libraries to share a single D runtime.

On Jan 10, 2013, at 6:43 AM, "evilrat" <evilrat666@gmail.com> wrote:

> On Thursday, 10 January 2013 at 14:07:38 UTC, Jacob Carlborg wrote:
>> On 2013-01-10 11:31, evilrat wrote:
>> 
>>> what's wrong with them? already used it on windows and mac, no problems so far, though not tested too deep, and not with D shared libs o_O
>> 
>> Apparently you haven't tested at all on Mac since it's only implemented on Windows:
>> 
>> https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L122
> 
> well like i said i don't used D shared libs yet.
> 
> umm.. looks simple at glance, whats the catch then if it still not implemented at least on osx?
January 10, 2013
On 2013-01-10 15:43, evilrat wrote:

> umm.. looks simple at glance, whats the catch then if it still not
> implemented at least on osx?

For loading regular C shared libraries there is no problem, just a simple wrapper around dlopen.

-- 
/Jacob Carlborg
January 10, 2013
On 2013-01-10 19:34, Jacob Carlborg wrote:

> For loading regular C shared libraries there is no problem, just a
> simple wrapper around dlopen.

For D shared libraries the problem is that I and Sean have said in other posts in this thread.

-- 
/Jacob Carlborg
January 10, 2013
On Thursday, 10 January 2013 at 18:34:52 UTC, Jacob Carlborg wrote:
> On 2013-01-10 19:34, Jacob Carlborg wrote:
>
>> For loading regular C shared libraries there is no problem, just a
>> simple wrapper around dlopen.
>
> For D shared libraries the problem is that I and Sean have said in other posts in this thread.

Thanks for the replies.

So if I understand all this correctly, I can safely load C plugins and use them reliably, but I cannot yet use D plugins. Correct?

--rt
January 10, 2013
On 2013-01-10 21:21, Rob T wrote:

> So if I understand all this correctly, I can safely load C plugins and
> use them reliably, but I cannot yet use D plugins. Correct?

Yes. But as I've said, these functions are only implemented for Windows. "dlopen" will work fine on Posix.

-- 
/Jacob Carlborg
January 10, 2013
On Thursday, 10 January 2013 at 20:48:00 UTC, Jacob Carlborg wrote:
> On 2013-01-10 21:21, Rob T wrote:
>
>> So if I understand all this correctly, I can safely load C plugins and
>> use them reliably, but I cannot yet use D plugins. Correct?
>
> Yes. But as I've said, these functions are only implemented for Windows. "dlopen" will work fine on Posix.

OK so these functions are not yet portable as stated in the documentation, and currently only work for Windows (the docs should be updated to state this).

I'm using Linux, so that means I have to use the usual dlopen, dlclose and dlsym? If so, this is at least a start, and I can safely load C shared libs as plugins.

BTW, where's the portable version of dlsym? Was the omission an oversight, or left out for a reason?

--rt
January 10, 2013
Am 10.01.2013 11:42, schrieb Jonathan M Davis:
> On Thursday, January 10, 2013 11:31:50 evilrat wrote:
>> what's wrong with them? already used it on windows and mac, no problems so far, though not tested too deep, and not with D shared libs o_O
> 
> C shared libraries are fine. It's D shared libraries that are the problem. I don't remember the details, but IIRC, among other things, you end up with multiple copies of the GC running. The runtime needs a variety of non-trivial tweaks to it order to fix those problems before shared D libraries become viable.
> 
> - Jonathan M Davis
> 

Multiple GC copies are result from an ODR violation. We need a shared phobos/druntime library to support other shared libraries.

January 11, 2013
On Thursday, 10 January 2013 at 23:57:10 UTC, Martin Nowak wrote:
> Multiple GC copies are result from an ODR violation. We need a shared
> phobos/druntime library to support other shared libraries.

Could you quickly summarize the current state of your related work? I might be able to spend some time on the issue in a few weeks if nobody beats me to it, but I'd rather not re-discover all of the problems that might be blocking your approach myself.

David
January 11, 2013
On Fri, Jan 11, 2013 at 12:54:40AM +0100, Rob T wrote: [...]
> I'm using Linux, so that means I have to use the usual dlopen, dlclose and dlsym? If so, this is at least a start, and I can safely load C shared libs as plugins.
> 
> BTW, where's the portable version of dlsym? Was the omission an oversight, or left out for a reason?
[...]

Are you talking about the D wrappers for dlsym, or the fact that dlsym is non-portable?


T

-- 
WINDOWS = Will Install Needless Data On Whole System -- CompuMan