January 11, 2013
On Friday, 11 January 2013 at 00:05:32 UTC, H. S. Teoh wrote:
> 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

I was referring to the portable D wrapper for dlsym, it seems to be missing by oversight, or was not implemented for some specific technical reason.

--rt
January 11, 2013
> About D shared libraries, this is what's missing:
> 
> The runtime need to collect the following from all loaded images (shared libraries and executables) and all that are loaded during program execution:
> 
> * Exception handling tables
> * Ranges scanned by the GC
> * TLS data
> 
> There are more issues than listed above that I can remember right now.
> 

Right this is the same state on POSIX and of 2.061 all shared libraries produced by dmd try to call a weakly linked `_d_dso_registry` upon loading/unloading to pass EH and ModuleInfo tables. https://github.com/D-Programming-Language/dmd/pull/1043/files#L0R3112

The current state of:
https://github.com/dawgfoto/druntime/tree/SharedRuntime
https://github.com/dawgfoto/phobos/tree/SharedRuntime
is here:
http://forum.dlang.org/post/op.wcrffp2asqugbd@localhost

Some unsolved issues remain: http://forum.dlang.org/post/mailman.2052.1325532031.24802.digitalmars-d@puremagic.com
January 11, 2013
> Could you quickly summarize the current state of your related work?

Please have a look at my other post in this thread. http://forum.dlang.org/post/50EF5875.1060009@dawg.eu

January 11, 2013
On Thursday, 10 January 2013 at 23:54:41 UTC, Rob T wrote:
>
> 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

a "portable" version with what we already know commented in
http://pastebin.com/rz5xPy8W
January 11, 2013
On 1/9/2013 11:35 PM, Rob T wrote:
> http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
>
> I want to load shared libraries during runtime as plug-in's, but the consensus
> seemed to indicate that DMD is not yet ready for this. I wonder if these
> functions provide any useful plug-in support or not?


Windows or Linux?
January 11, 2013
On 1/10/2013 2:42 AM, Jonathan M Davis wrote:
> 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.


This was fixed in D1 long ago. DLLs would use the Executable's gc instance.
January 11, 2013
On Friday, 11 January 2013 at 02:19:32 UTC, Walter Bright wrote:
> On 1/9/2013 11:35 PM, Rob T wrote:
>> http://dlang.org/phobos/core_runtime.html#.Runtime.loadLibrary
>>
>> I want to load shared libraries during runtime as plug-in's, but the consensus
>> seemed to indicate that DMD is not yet ready for this. I wonder if these
>> functions provide any useful plug-in support or not?
>
>
> Windows or Linux?

The more immediate need for me is definitely Linux.

--rt
January 11, 2013
On Friday, 11 January 2013 at 02:20:27 UTC, Walter Bright wrote:
> On 1/10/2013 2:42 AM, Jonathan M Davis wrote:
>> 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.
>
>
> This was fixed in D1 long ago. DLLs would use the Executable's gc instance.

Wait.. this was a bit unclear, but it sounded like you just said D's DLL issues where fixed awhile ago.. Is D2 capable of correctly loading DLLs? What's the situation with Linux?
January 11, 2013
On Friday, 11 January 2013 at 06:26:56 UTC, F i L wrote:
> Wait.. this was a bit unclear, but it sounded like you just said D's DLL issues where fixed awhile ago.. Is D2 capable of correctly loading DLLs? What's the situation with Linux?

look for the link in this topic to the d runtime source (dmain2.d file), there is static assert in Runtime.loadLibrary(...) for non windows, it shouldn't compile at all, but if i remember on OSX it compiled for me. no really, can't remember...
January 11, 2013
On Friday, 11 January 2013 at 06:40:00 UTC, evilrat wrote:
> On Friday, 11 January 2013 at 06:26:56 UTC, F i L wrote:
>> Wait.. this was a bit unclear, but it sounded like you just said D's DLL issues where fixed awhile ago.. Is D2 capable of correctly loading DLLs? What's the situation with Linux?
>
> look for the link in this topic to the d runtime source (dmain2.d file), there is static assert in Runtime.loadLibrary(...) for non windows, it shouldn't compile at all, but if i remember on OSX it compiled for me. no really, can't remember...

oops, my bad, there is exception throwed.