On Friday, 2 June 2017 at 16:36:34 UTC, H. S. Teoh wrote:
> On Fri, Jun 02, 2017 at 12:19:48PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
>> [...]
> [...]
>
> This is not directly related to the OP's question, but recently I wrote a program that, given a user-specified string, transforms it into D code using a code template, invokes dmd to compile it into a shared object, loads the shared object using dlopen(), and looks up the generated function with dlsym() to obtain a function pointer that can be used for calling the function. The shared object is unloaded after it's done.
>
> [...]
Blog on it?

On Friday, 2 June 2017 at 16:36:34 UTC, H. S. Teoh wrote:
> On Fri, Jun 02, 2017 at 12:19:48PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
>> On Friday, 2 June 2017 at 11:09:05 UTC, aberba wrote:
>> > 1. Get shared libs to work in D (the best approach for all D code)
>> 
>> I have done very little with this myself but other people have so it is doable.
> [...]
>
> This is not directly related to the OP's question, but recently I wrote a program that, given a user-specified string, transforms it into D code using a code template, invokes dmd to compile it into a shared object, loads the shared object using dlopen(), and looks up the generated function with dlsym() to obtain a function pointer that can be used for calling the function. The shared object is unloaded after it's done.

Will be of much use to me to see the brief instructions for this. I saw the C style on Wikipedia.

Seems the functions loaded needs to be casted from void* to a type... before calling. Didn't quite understand that part.

>
> So it's definitely doable, in the sense that I've successfully generated D code, compiled it into a shared library, loaded it into the running executable, and can call the code.  Of course, in my case, the code template is relatively simple so I don't have to worry about things like module ctors, shared data, non-TLS globals, or GC use.  If you're planning to support those features, you might need to do a bit more work after calling dlopen(). At the very least you'd have to use dlsym() to look up module ctor symbols and run them before calling any other functions in the shared object, and you may have to initialize druntime in the shared object too, if it's statically linked.

That seem like D with its features will be lot of work if I'm using loaded code that way.

How about exposing standard interface/apis for loaded object's code to query info about the main app at runtime, similar to COM (if that's how if even works)

> I'm not sure what happens if it's dynamically linked, or if it uses its own copy of the GC.
>
Does D work different from C in that regard?

> In any case, this is all possible, it just takes someone to dig into the details and write the code to make it all work.  Then publish it on github or dub, and the rest of us can reap the benefits too. ;-)
>
>
> T

On Saturday, 3 June 2017 at 09:41:58 UTC, aberba wrote:
> On Friday, 2 June 2017 at 16:36:34 UTC, H. S. Teoh wrote:
>> On Fri, Jun 02, 2017 at 12:19:48PM +0000, Adam D. Ruppe via Digitalmars-d-learn wrote:
>>> On Friday, 2 June 2017 at 11:09:05 UTC, aberba wrote:
>>> > 1. Get shared libs to work in D (the best approach for all D code)
>>> 
>>> I have done very little with this myself but other people have so it is doable.
>> [...]
>>
>> This is not directly related to the OP's question, but recently I wrote a program that, given a user-specified string, transforms it into D code using a code template, invokes dmd to compile it into a shared object, loads the shared object using dlopen(), and looks up the generated function with dlsym() to obtain a function pointer that can be used for calling the function. The shared object is unloaded after it's done.
>
> Will be of much use to me to see the brief instructions for this. I saw the C style on Wikipedia.
>
> Seems the functions loaded needs to be casted from void* to a type... before calling. Didn't quite understand that part.
>
Yes, dlsym() returns the address of the object of the shared library you requested. The first parameter is the handle to the shared object that had been loaded by dlopen(). The second parameter is the name of the object one wants the address of.
The address must then be casted to the type of the object. If the name was one of a function, one has to cast to a function pointer. That's something illegal in strict C (i.e. undefined behaviour.) but is something that is required by Posix. It's really not very difficult.