Re: Linux shared library loading/linking from C does not invoke (shared) static this
On Tuesday, 12 January 2021 at 09:49:46 UTC, Mike Parker wrote: On Tuesday, 12 January 2021 at 09:31:08 UTC, ichneumwn wrote: Follow on to my own question: on Linux, with gcc, I have created the following file "starter.c" that I inject into my D shared library: int rt_init(void); int rt_term(void); // should really check for errors! static void __attribute__((constructor)) Dstarter(void) { rt_init(); } static void __attribute__((destructor)) Dterminator(void) { rt_term(); } That seems to do the trick. Not sure how clean this is? You should be able to do the same in D with `pragma(crt_constructor)` and `pragma(crt_destructor)`: https://dlang.org/spec/pragma.html#crtctor https://dlang.org/spec/pragma.html#crtdtor https://dlang.org/changelog/2.078.0.html#crt-constructor Perfect, thanks! Interestingly, as I removed the C stub and tried the D route, I noticed that just calling rt_init() is enough to also get static ~this() to run on exit. In fact then adding writeln in a pragma(crt_destructor) function shows that it gets called after static ~this(). For anyone stumbling across this thread and looking for the import for rt_init/term: import core.runtime : rt_init, rt_term;
Re: Linux shared library loading/linking from C does not invoke (shared) static this
On Tuesday, 12 January 2021 at 09:02:38 UTC, Imperatorn wrote: On Tuesday, 12 January 2021 at 08:19:45 UTC, ichneumwn wrote: Where could one file a suggestion for an update to the documentation? In the top right section of the page you can click the "Improve this page"-link. Thanks, I will leave it though. I do not want to mess about and write about something I have just learnt in the last hour. That could do more damage than good.
Re: Linux shared library loading/linking from C does not invoke (shared) static this
On Tuesday, 12 January 2021 at 08:19:45 UTC, ichneumwn wrote: Dear all, I was trying to invoke some D code from Python and ran into issues which I eventually traced back to a simple example on the D website itself : https://dlang.org/articles/dll-linux.html Particularly the section "Dynamically Loading a D DLL From a C Program" In my case, and indeed already in 2013 (https://forum.dlang.org/post/yeqyqaaguhngczlnv...@forum.dlang.org), shared static this does not get invoked I normally use: LDC - the LLVM D compiler (1.21.0): based on DMD v2.091.1 and LLVM 10.0.0 (under Linux) but I also tried DMD64 D Compiler v2.095.0 Is the solution suggested in the linked post the "canonical way"? Where could one file a suggestion for an update to the documentation? Cheers! PS Enjoying my project in D especially how easy it is to get the same code to run under windows too Follow on to my own question: on Linux, with gcc, I have created the following file "starter.c" that I inject into my D shared library: int rt_init(void); int rt_term(void); // should really check for errors! static void __attribute__((constructor)) Dstarter(void) { rt_init(); } static void __attribute__((destructor)) Dterminator(void) { rt_term(); } That seems to do the trick. Not sure how clean this is?
Linux shared library loading/linking from C does not invoke (shared) static this
Dear all, I was trying to invoke some D code from Python and ran into issues which I eventually traced back to a simple example on the D website itself : https://dlang.org/articles/dll-linux.html Particularly the section "Dynamically Loading a D DLL From a C Program" In my case, and indeed already in 2013 (https://forum.dlang.org/post/yeqyqaaguhngczlnv...@forum.dlang.org), shared static this does not get invoked I normally use: LDC - the LLVM D compiler (1.21.0): based on DMD v2.091.1 and LLVM 10.0.0 (under Linux) but I also tried DMD64 D Compiler v2.095.0 Is the solution suggested in the linked post the "canonical way"? Where could one file a suggestion for an update to the documentation? Cheers! PS Enjoying my project in D especially how easy it is to get the same code to run under windows too
Re: Waiting on file descriptor/socket *AND* thread messages
On Monday, 29 June 2020 at 12:25:16 UTC, Steven Schveighoffer wrote: On 6/29/20 5:14 AM, ichneumwn wrote: [...] Not in the standard library. Such things require an event framework, because there is no OS-agnostic provided mechanism to sleep on all these things at once. I recommend looking through code.dlang.org. I found these: https://code.dlang.org/packages/libasync https://code.dlang.org/packages/eventcore https://code.dlang.org/packages/mecca (this seems very underdocumented, but I know it provides such a system) [...] I don't know the correct way to solve this, I've done it in the past by creating a file descriptor that can be waited on to wake up the target along with any other file descriptors being waited on. -Steve Thanks for the pointers Steve!
Waiting on file descriptor/socket *AND* thread messages
Dear all, Is there some facility in D for a single statement/function call that will wait on both file descriptors, like Socket.select(), and will also wake up when there is something to be receive()'d? One solution would be to have my main thread use receive() and a helper thread that does the select() call and sends a message to the main thread. That seems a bit of overkill however. Apologies if this has been asked before, but my google search and search in this thread were fruitless (could be my searching skills) Cheers