On 10/16/20 4:12 PM, WhatMeWorry wrote:
> Isn't dlopen() for Linux
More like dlopen() is for Posix, which means it should be available on
Windows as well.
However, as I've discovered, a D shared library cannot be loaded with
dlopen() because the main program and the shared library would do
On Friday, 16 October 2020 at 15:14:03 UTC, Ali Çehreli wrote:
On 10/15/20 2:42 PM, Ali Çehreli wrote:
> I've recently done the same by calling dlopen() and dlsym()
> directly. Runtime.loadLibrary documentation says "If the
library
> contains a D runtime it will be integrated with the current
On 10/15/20 2:42 PM, Ali Çehreli wrote:
> I've recently done the same by calling dlopen() and dlsym()
> directly. Runtime.loadLibrary documentation says "If the library
> contains a D runtime it will be integrated with the current runtime."
> That would explain why my program seg-faults for my
On Thu, Oct 15, 2020 at 09:47:16PM +, IGotD- via Digitalmars-d-learn wrote:
> On Thursday, 15 October 2020 at 21:29:59 UTC, WhatMeWorry wrote:
> >
> > I've go a small DLL and a test module both written in D. Why do I
> > need to use the extern(C)? Shouldn't both sides be using D name
> >
On Thursday, 15 October 2020 at 21:29:59 UTC, WhatMeWorry wrote:
I've go a small DLL and a test module both written in D. Why do
I need to use the extern(C)? Shouldn't both sides be using D
name wrangling?
You have answered your own question. If you're not using
extern(C), D just like
On 10/15/20 2:29 PM, WhatMeWorry wrote:
> name wrangling?
Name mangling. :) I don't know the answer but I can hijack your thread.
> import core.runtime;
> auto mydll = Runtime.loadLibrary("mydll.dll");
Interesting. I've recently done the same by calling dlopen() and dlsym()
I've go a small DLL and a test module both written in D. Why do I
need to use the extern(C)? Shouldn't both sides be using D name
wrangling?
mydll.d
module mydll;
extern(C): // removing or changing to (D): results in error
export
{
