www.digitalmars.com         C & C++   DMDScript  

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

reply "Rob T" <alanb ucora.com> writes:


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:


 
 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 reply "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:


 
 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
next sibling parent reply 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
next sibling parent reply "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
next sibling parent reply 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
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 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 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 "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
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 "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
next sibling parent reply "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
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 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 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 "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
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


=20
 Apparently you haven't tested at all on Mac since it's only implemented o=




n Windows:

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




in2.d#L122

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


nted at least on osx?
Jan 10 2013
prev sibling 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 "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
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 reply "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
next sibling parent reply "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
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 reply "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
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 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 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 Walter Bright <newshound2 digitalmars.com> writes:
On 1/9/2013 11:35 PM, Rob T wrote:



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



 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 parent reply "Phil Lavoie" <maidenphil hotmail.com> writes:
On Thursday, 10 January 2013 at 07:35:54 UTC, Rob T wrote:



 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
next sibling parent reply "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:



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



 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


+1
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 * =


whateverReturnedByLoadLib, string name )" function?

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




wrote:

=20

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


=20
 Please submit an enhancement request :-)


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


functions?

=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? =


Would

 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