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

> 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

> 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

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

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?

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.

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

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?

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

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.