www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - core.runtime: loadLibrary and unloadLibrary?

reply "Rob T" <alanb ucora.com> writes:
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?

Thanks!

--rt
Jan 09 2013
next sibling parent reply Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 10, 2013 08:35:53 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?

I don't know what the state of those functions is, but the GC can't handle shared libraries at this point. I believe that that's the main reason why shared libraries are a no-go at this point. And with a problem like that, it seems to me like a _really_ bad idea to try and use them. If I were you, I'd keep away from them until druntime was fixed to properly support them. That's certainly what I intend to do. - Jonathan M Davis
Jan 09 2013
next sibling parent Jacob Carlborg <doob me.com> writes:
On 2013-01-10 11:54, evilrat wrote:

 tweaks like this http://dlang.org/dll.html#Dcode ?

Tweaks like this: https://github.com/dawgfoto/druntime/tree/SharedRuntime -- /Jacob Carlborg
Jan 10 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
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 -- /Jacob Carlborg
Jan 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
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
Jan 10 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-11 00:54, 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).

Yes, please file a bug report. Either to fix the documentation or implement the functions for Posix. The Posix functions can be implemented to only work for C shared libraries.
 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.

Yes. -- /Jacob Carlborg
Jan 10 2013
prev sibling next sibling parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-10 08:51, Jonathan M Davis wrote:

 I don't know what the state of those functions is, but the GC can't handle
 shared libraries at this point. I believe that that's the main reason why
 shared libraries are a no-go at this point. And with a problem like that, it
 seems to me like a _really_ bad idea to try and use them. If I were you, I'd
 keep away from them until druntime was fixed to properly support them. That's
 certainly what I intend to do.

The state is that they're only implement on Windows: https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dmain2.d#L122 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. -- /Jacob Carlborg
Jan 10 2013
parent reply Martin Nowak <code dawg.eu> writes:
 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
Jan 10 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-11 01:10, Martin Nowak wrote:

 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

This code seems to only be fore ELF targets. This is not needed on Mac OS X, right? Bracketed sections are not needed on Mac OS X.
 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

Thanks for the update. This looks interesting. -- /Jacob Carlborg
Jan 10 2013
prev sibling next sibling parent reply Martin Nowak <code dawg.eu> writes:
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.
Jan 10 2013
parent reply Martin Nowak <code dawg.eu> writes:
 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
Jan 10 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-11 01:28, Martin Nowak wrote:
 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

I think we need to start tracking these issues in bugzilla. -- /Jacob Carlborg
Jan 10 2013
prev sibling parent reply Walter Bright <newshound2 digitalmars.com> writes:
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.
Jan 10 2013
parent reply Jacob Carlborg <doob me.com> writes:
On 2013-01-11 07:26, 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?

I'm pretty sure that when he says "DLL" he means DLL on Windows. So the situation is that we cannot correctly use D shared libraries on Posix. -- /Jacob Carlborg
Jan 10 2013
parent reply Walter Bright <newshound2 digitalmars.com> writes:
On 1/10/2013 11:44 PM, Jacob Carlborg wrote:
 On 2013-01-11 07:26, 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?

I'm pretty sure that when he says "DLL" he means DLL on Windows. So the situation is that we cannot correctly use D shared libraries on Posix.

"DLL" is Windows "shared library" is Linux/OSX/FreeBSD
Jan 11 2013
parent Jacob Carlborg <doob me.com> writes:
On 2013-01-11 09:21, Walter Bright wrote:

 "DLL" is Windows
 "shared library" is Linux/OSX/FreeBSD

Some people have a tendency to mix the terms. I like to call it "dynamic library" on all platforms. -- /Jacob Carlborg
Jan 11 2013
prev sibling next sibling parent "evilrat" <evilrat666 gmail.com> writes:
On Thursday, 10 January 2013 at 07:52:19 UTC, Jonathan M Davis 
wrote:
 On Thursday, January 10, 2013 08:35:53 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?

I don't know what the state of those functions is, but the GC can't handle shared libraries at this point. I believe that that's the main reason why shared libraries are a no-go at this point. And with a problem like that, it seems to me like a _really_ bad idea to try and use them. If I were you, I'd keep away from them until druntime was fixed to properly support them. That's certainly what I intend to do. - Jonathan M Davis

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
Jan 10 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
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
Jan 10 2013
prev sibling next sibling parent "evilrat" <evilrat666 gmail.com> writes:
On Thursday, 10 January 2013 at 10:43:14 UTC, Jonathan M Davis 
wrote:
 The runtime needs a variety of non-trivial tweaks to it order 
 to fix those problems before shared D libraries become viable.

tweaks like this http://dlang.org/dll.html#Dcode ?
Jan 10 2013
prev sibling next sibling parent Jonathan M Davis <jmdavisProg gmx.com> writes:
On Thursday, January 10, 2013 11:54:03 evilrat wrote:
 On Thursday, 10 January 2013 at 10:43:14 UTC, Jonathan M Davis
 
 wrote:
 The runtime needs a variety of non-trivial tweaks to it order
 to fix those problems before shared D libraries become viable.

tweaks like this http://dlang.org/dll.html#Dcode ?

I don't know any of the details, but that page does seem to discuss at least some of the issues. Other folks around here are far more familiar with what the exact situation is than I am. - Jonathan M Davis
Jan 10 2013
prev sibling next sibling parent "evilrat" <evilrat666 gmail.com> writes:
On Thursday, 10 January 2013 at 11:00:55 UTC, Jonathan M Davis 
wrote:
 On Thursday, January 10, 2013 11:54:03 evilrat wrote:
 On Thursday, 10 January 2013 at 10:43:14 UTC, Jonathan M Davis
 
 wrote:
 The runtime needs a variety of non-trivial tweaks to it order
 to fix those problems before shared D libraries become 
 viable.

tweaks like this http://dlang.org/dll.html#Dcode ?

I don't know any of the details, but that page does seem to discuss at least some of the issues. Other folks around here are far more familiar with what the exact situation is than I am. - Jonathan M Davis

well anyway thanks for info, this would definitely save some time if i encounter some bugs while doing D shared libs.
Jan 10 2013
prev sibling next sibling parent "evilrat" <evilrat666 gmail.com> writes:
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?
Jan 10 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
I think the main issue is scanning static memory segments in the shared libr=
ary during collections. Pretty sure this is sorted for Windows, but I think w=
ork still needs to be done for other platforms.  It's been a while since I'v=
e 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 s=
hould be fine. The trick is getting all shared libraries to share a single D=
 runtime.=20

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:
=20
 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 o=


=20
 https://github.com/D-Programming-Language/druntime/blob/master/src/rt/dma=


=20
 well like i said i don't used D shared libs yet.
=20
 umm.. looks simple at glance, whats the catch then if it still not impleme=

Jan 10 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
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
Jan 10 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
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
Jan 10 2013
prev sibling next sibling parent "David Nadlinger" <see klickverbot.at> writes:
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
Jan 10 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
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
Jan 10 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
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
Jan 10 2013
prev sibling next sibling parent "evilrat" <evilrat666 gmail.com> writes:
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
Jan 10 2013
prev sibling next sibling parent Walter Bright <newshound2 digitalmars.com> writes:
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?
Jan 10 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
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
Jan 10 2013
prev sibling next sibling parent "F i L" <witte2008 gmail.com> writes:
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?
Jan 10 2013
prev sibling next sibling parent "evilrat" <evilrat666 gmail.com> writes:
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...
Jan 10 2013
prev sibling next sibling parent "evilrat" <evilrat666 gmail.com> writes:
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.
Jan 10 2013
prev sibling next sibling parent "Phil Lavoie" <maidenphil hotmail.com> writes:
On Thursday, 10 January 2013 at 07:35:54 UTC, 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?

 Thanks!

 --rt

Speaking of which, Anyone else finds themself desiring a "loadSymbol( void * whateverReturnedByLoadLib, string name )" function? Phil
Jan 11 2013
prev sibling next sibling parent "evilrat" <evilrat666 gmail.com> writes:
On Friday, 11 January 2013 at 15:34:33 UTC, Phil Lavoie wrote:
 On Thursday, 10 January 2013 at 07:35:54 UTC, 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?

 Thanks!

 --rt

Speaking of which, Anyone else finds themself desiring a "loadSymbol( void * whateverReturnedByLoadLib, string name )" function? Phil

it's not a desire, it's must have! O_o
Jan 11 2013
prev sibling next sibling parent "Phil Lavoie" <maidenphil hotmail.com> writes:
On Friday, 11 January 2013 at 15:36:29 UTC, evilrat wrote:
 On Friday, 11 January 2013 at 15:34:33 UTC, Phil Lavoie wrote:
 On Thursday, 10 January 2013 at 07:35:54 UTC, 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?

 Thanks!

 --rt

Speaking of which, Anyone else finds themself desiring a "loadSymbol( void * whateverReturnedByLoadLib, string name )" function? Phil

it's not a desire, it's must have! O_o

Jan 11 2013
prev sibling next sibling parent "Rob T" <alanb ucora.com> writes:
On Friday, 11 January 2013 at 02:13:51 UTC, evilrat wrote:
 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

Thanks for that! I'll make use of that for my C plugins. --rt
Jan 11 2013
prev sibling next sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jan 11, 2013, at 7:34 AM, Phil Lavoie <maidenphil hotmail.com> wrote:

 Anyone else finds themself desiring a "loadSymbol( void * =

Please submit an enhancement request :-)=
Jan 11 2013
prev sibling next sibling parent "H. S. Teoh" <hsteoh quickfur.ath.cx> writes:
On Fri, Jan 11, 2013 at 11:26:33AM -0800, Sean Kelly wrote:
 On Jan 11, 2013, at 7:34 AM, Phil Lavoie <maidenphil hotmail.com> wrote:
 
 Anyone else finds themself desiring a "loadSymbol( void *
 whateverReturnedByLoadLib, string name )" function?

Please submit an enhancement request :-)

Is it safe to use void* for representing _both_ variables and functions? I know in C++ this was a problem in the standard, because a function pointer may not be the same size as a pointer to a variable, and therefore dlsym technically has undefined behaviour (though I doubt if any implementation actually doesn't work). What's the situation in D? What if the library exports delegates? Would it be dangerous to cast it to void*? Do we need separate functions for loading function symbols vs. data symbols? T -- Give me some fresh salted fish, please.
Jan 11 2013
prev sibling parent Sean Kelly <sean invisibleduck.org> writes:
On Jan 11, 2013, at 12:41 PM, H. S. Teoh <hsteoh quickfur.ath.cx> wrote:

 On Fri, Jan 11, 2013 at 11:26:33AM -0800, Sean Kelly wrote:
 On Jan 11, 2013, at 7:34 AM, Phil Lavoie <maidenphil hotmail.com> =


=20
 Anyone else finds themself desiring a "loadSymbol( void *
 whateverReturnedByLoadLib, string name )" function?

Please submit an enhancement request :-)

Is it safe to use void* for representing _both_ variables and =

=20
 I know in C++ this was a problem in the standard, because a function
 pointer may not be the same size as a pointer to a variable, and
 therefore dlsym technically has undefined behaviour (though I doubt if
 any implementation actually doesn't work).
=20
 What's the situation in D? What if the library exports delegates? =

 it be dangerous to cast it to void*? Do we need separate functions for
 loading function symbols vs. data symbols?

I don't think a library can directly export a delegate, because that = implies a context pointer linked to instantiated data. void* is safe = provided that's what the underlying API uses. It may be a better idea = to change this to an opaque handle though.=
Jan 11 2013