digitalmars.D - Dynamic loading
- Steve Teale (1/1) Oct 27 2013 Any progress?
- Benjamin Thaut (6/7) Oct 27 2013 Yes. The implementation of the linux part seems to be done and will be
-
evilrat
(9/16)
Oct 27 2013
- QAston (3/11) Oct 27 2013 It's time to learn that life is cruel and unjust and people don't
- Benjamin Thaut (8/24) Oct 27 2013 You are welcome to discuss DIP 45 which aims to fix "export" so that
- Jacob Carlborg (5/11) Oct 27 2013 We most likely need native TLS for Mac OS X before supporting dynamic
- Dicebot (2/3) Oct 27 2013 So glad to see this becoming a common wisdom :P
- Steve Teale (2/9) Oct 27 2013 Thanks Benjamin - Linux will suit me ;=)
- Steve Teale (3/10) Oct 28 2013 Is there a description somewhere of how this will work? Is it
- Jacob Carlborg (4/6) Oct 28 2013 I guess it's compiler and runtime.
- Steve Teale (5/10) Oct 28 2013 That sounds a bit implausible. New language keyword or something
- Dicebot (10/14) Oct 28 2013 1) it is not new, it is the old one that needs fixing :
- Jacob Carlborg (6/10) Oct 28 2013 Sorry, I wasn't very clear. The correct function to use is
- Steve Teale (3/14) Oct 29 2013 I was forgetting the runtime library - that seems like the place
- Jacob Carlborg (6/17) Oct 28 2013 It's not completely done yet but I think
- David Nadlinger (7/18) Oct 28 2013 In the current implementation, just loading a library using the C
- Martin Nowak (12/16) Oct 29 2013 We need another runtime layer to account for per-thread
- Martin Nowak (8/15) Oct 29 2013 Not entirely true.
- Flamaros (13/14) Oct 28 2013 There is no way to do something best with llvm?
- evilrat (4/18) Oct 28 2013 to be honest, many C/C++ developers don't think it is portable,
- Flamaros (2/22) Oct 29 2013
- Moritz Maxeiner (7/13) Oct 29 2013 LLVM IR is not fully cross-platform, sadly. Sure, the more basic,
Am 27.10.2013 09:08, schrieb Steve Teale:Any progress?Yes. The implementation of the linux part seems to be done and will be included in 2.064. On windows it will take some time because "export" has to be fixed first. Kind Regards Benjamin Thaut
Oct 27 2013
On Sunday, 27 October 2013 at 08:23:26 UTC, Benjamin Thaut wrote:Am 27.10.2013 09:08, schrieb Steve Teale:<sarcasm> wow. cool. most people developing(using) linux version. so what do we have: we(me?) have COM problems(can't figure what causes them). we have OS X development which is still real hardcore. but wait, we have more and more working linux version, who need other OS if we had linux \0/ </sarcasm>Any progress?Yes. The implementation of the linux part seems to be done and will be included in 2.064. On windows it will take some time because "export" has to be fixed first. Kind Regards Benjamin Thaut
Oct 27 2013
"QAston" <qaston gmail.com> On Sunday, 27 October 2013 at 08:52:02 UTC, evilrat wrote:<sarcasm> wow. cool. most people developing(using) linux version. so what do we have: we(me?) have COM problems(can't figure what causes them). we have OS X development which is still real hardcore. but wait, we have more and more working linux version, who need other OS if we had linux \0/ </sarcasm>It's time to learn that life is cruel and unjust and people don't do whatever they're ask to do :P.
Oct 27 2013
Am 27.10.2013 09:52, schrieb evilrat:On Sunday, 27 October 2013 at 08:23:26 UTC, Benjamin Thaut wrote:You are welcome to discuss DIP 45 which aims to fix "export" so that shared library support can be added to windows plattforms. You are also welcome to point out wherever you can that you are interrested in shared library support for windows. http://forum.dlang.org/thread/kvhu2c$2ikq$1 digitalmars.com#post-kvhu2c:242ikq:241:40digitalmars.com Kind Regards Benjamin ThautAm 27.10.2013 09:08, schrieb Steve Teale:<sarcasm> wow. cool. most people developing(using) linux version. so what do we have: we(me?) have COM problems(can't figure what causes them). we have OS X development which is still real hardcore. but wait, we have more and more working linux version, who need other OS if we had linux \0/ </sarcasm>Any progress?Yes. The implementation of the linux part seems to be done and will be included in 2.064. On windows it will take some time because "export" has to be fixed first. Kind Regards Benjamin Thaut
Oct 27 2013
On 2013-10-27 09:52, evilrat wrote:<sarcasm> wow. cool. most people developing(using) linux version. so what do we have: we(me?) have COM problems(can't figure what causes them). we have OS X development which is still real hardcore. but wait, we have more and more working linux version, who need other OS if we had linux \0/ </sarcasm>We most likely need native TLS for Mac OS X before supporting dynamic libraries. -- /Jacob Carlborg
Oct 27 2013
On Sunday, 27 October 2013 at 08:52:02 UTC, evilrat wrote:who need other OS if we had linux \0/So glad to see this becoming a common wisdom :P
Oct 27 2013
On Sunday, 27 October 2013 at 08:23:26 UTC, Benjamin Thaut wrote:Am 27.10.2013 09:08, schrieb Steve Teale:Thanks Benjamin - Linux will suit me ;=)Any progress?Yes. The implementation of the linux part seems to be done and will be included in 2.064. On windows it will take some time because "export" has to be fixed first. Kind Regards Benjamin Thaut
Oct 27 2013
On Sunday, 27 October 2013 at 08:23:26 UTC, Benjamin Thaut wrote:Am 27.10.2013 09:08, schrieb Steve Teale:Is there a description somewhere of how this will work? Is it language, Phobos, linker, or what.Any progress?Yes. The implementation of the linux part seems to be done and will be included in 2.064. On windows it will take some time because "export" has to be fixed first. Kind Regards Benjamin Thaut
Oct 28 2013
On 2013-10-28 18:45, Steve Teale wrote:Is there a description somewhere of how this will work? Is it language, Phobos, linker, or what.I guess it's compiler and runtime. -- /Jacob Carlborg
Oct 28 2013
On Monday, 28 October 2013 at 17:49:23 UTC, Jacob Carlborg wrote:On 2013-10-28 18:45, Steve Teale wrote:That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.Is there a description somewhere of how this will work? Is it language, Phobos, linker, or what.I guess it's compiler and runtime.
Oct 28 2013
On Monday, 28 October 2013 at 18:01:14 UTC, Steve Teale wrote:That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.1) it is not new, it is the old one that needs fixing : http://dlang.org/attribute.html#ProtectionAttribute 2) it work just fine in Linux (dlopen) because all symbols are exported there by default. Proper symbol visibility definition is still needed for any cross-platform implementation (and for some optimization potential). Right now on Linux naive dlopen + calling Phobos stdio function from shared lib works on 2.064beta so you can be calm about that part.
Oct 28 2013
On 2013-10-28 19:00, Steve Teale wrote:That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.Sorry, I wasn't very clear. The correct function to use is core.runtime.Runtime.loadLibrary: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L178 -- /Jacob Carlborg
Oct 28 2013
On Monday, 28 October 2013 at 20:42:00 UTC, Jacob Carlborg wrote:On 2013-10-28 19:00, Steve Teale wrote:I was forgetting the runtime library - that seems like the place ;=)That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.Sorry, I wasn't very clear. The correct function to use is core.runtime.Runtime.loadLibrary: https://github.com/D-Programming-Language/druntime/blob/master/src/core/runtime.d#L178
Oct 29 2013
On 2013-10-28 19:00, Steve Teale wrote:On Monday, 28 October 2013 at 17:49:23 UTC, Jacob Carlborg wrote:It's not completely done yet but I think core.runtime.Runtime.loadLibrary will be the function used to load libraries. See: https://github.com/D-Programming-Language/druntime/pull/617 -- /Jacob CarlborgOn 2013-10-28 18:45, Steve Teale wrote:That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.Is there a description somewhere of how this will work? Is it language, Phobos, linker, or what.I guess it's compiler and runtime.
Oct 28 2013
On Monday, 28 October 2013 at 20:44:11 UTC, Jacob Carlborg wrote:In the current implementation, just loading a library using the C functions would indeed work, as the D runtime registration/initialization happens in a C .ctor. The actual implementation in druntime is a bit more complex, mainly to handle thread synchronization. DavidThat sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.It's not completely done yet but I think core.runtime.Runtime.loadLibrary will be the function used to load libraries. See: https://github.com/D-Programming-Language/druntime/pull/617
Oct 28 2013
On 10/28/2013 07:00 PM, Steve Teale wrote:That sounds a bit implausible. New language keyword or something to load a library or object file. My best guess is that extern(C) dlopen() will just work correctly, failing that I'd think we need an equivalent Phobos call.We need another runtime layer to account for per-thread initialization/finalization of modules (static this()/static ~this()). There is Runtime.loadLibrary/Runtime.unloadLibrary and rt_loadLibrary/rt_unloadLibrary to do this. You can use dlopen from a C executable but the loaded D library is only usable from the loading thread. For a C executable the recommended pattern is to dlopen or link druntime (libphobos2.so) and to use rt_loadLibrary/rt_unloadLibrary to load D libraries. Currently the best available documentation are the tests (https://github.com/D-Programming-Language/druntime/tree/master/test/shared).
Oct 29 2013
On 10/27/2013 09:23 AM, Benjamin Thaut wrote:Am 27.10.2013 09:08, schrieb Steve Teale:Not entirely true. We have the basic low-level support but the high-level stuff isn't ready for this release (https://github.com/D-Programming-Language/druntime/pull/617). If you're curious you can try the low-level stuff. Currently the most accurate howto is the unittests :(, (https://github.com/D-Programming-Language/druntime/tree/master/test/shared).Any progress?Yes. The implementation of the linux part seems to be done and will be included in 2.064. On windows it will take some time because "export" has to be fixed first. Kind Regards Benjamin Thaut
Oct 29 2013
On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:Any progress?There is no way to do something best with llvm? I don't really understand why for static and dynamic libraries we need rely on OS implementation. llvm intermediate byte code isn't fast enough translatable at runtime? Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,... It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture.
Oct 28 2013
On Monday, 28 October 2013 at 22:25:12 UTC, Flamaros wrote:On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:maybe our childrens will see it one day :)Any progress?There is no way to do something best with llvm? I don't really understand why for static and dynamic libraries we need rely on OS implementation. llvm intermediate byte code isn't fast enough translatable at runtime? Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,...It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture.to be honest, many C/C++ developers don't think it is portable, so Java developers are not alone here O_-
Oct 28 2013
On Tuesday, 29 October 2013 at 04:28:24 UTC, evilrat wrote:On Monday, 28 October 2013 at 22:25:12 UTC, Flamaros wrote:It makes me sad :(On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:maybe our childrens will see it one day :)Any progress?There is no way to do something best with llvm? I don't really understand why for static and dynamic libraries we need rely on OS implementation. llvm intermediate byte code isn't fast enough translatable at runtime? Actual binaries format on Windows and Linux seems old and limited, I dream of cross platforms compilers that are based on binaries format that contains all necessary information to be able to operate correct inlining,...It's a real strength that VM based language have to be binary inter-operable. A lot of Java developers don't see C/C++ as portable languages just cause of the necessity to rebuild binaries on each OS even their runs on same architecture.to be honest, many C/C++ developers don't think it is portable, so Java developers are not alone here O_-
Oct 29 2013
On Monday, 28 October 2013 at 22:25:12 UTC, Flamaros wrote:On Sunday, 27 October 2013 at 08:08:08 UTC, Steve Teale wrote:LLVM IR is not fully cross-platform, sadly. Sure, the more basic, core feature are platform independent, but once you need more advanced features you will need to adjust the LLVM IR for your architecture, such as x86, x86_64, or ARM. I'd suggest to give this document a read on the topic: http://llvm.org/docs/LangRef.htmlAny progress?There is no way to do something best with llvm? I don't really understand why for static and dynamic libraries we need rely on OS implementation. llvm intermediate byte code isn't fast enough translatable at runtime?
Oct 29 2013