Shared library extern (C) variables
TheFlyingFiddle
kurtyan at student.chalmers.se
Sun Jan 5 13:15:19 PST 2014
On Sunday, 5 January 2014 at 19:55:50 UTC, Mineko wrote:
> Ahh I appreciate it, but I already have that part down and
> good. :)
>
> I was wondering about how to use export correctly, I apologize
> for not being clear.
>
> Also I'll keep in mind the __gshared, never even knew about it.
Export is currently somewhat broken see DIP45 for an indepth
explanation
(link)
To be able to load symbols from libraries at runtime they have to
be declared with extern. This rule does not hold on linux though
since it simply makes all the symbols avalible but for other
systems it is important.
So for instance:
void foo() { ... } //This will NOT be avalible for loading under
windows.
export void foo() { ... } //This is avalible for loading under
windows.
extern(C) void foo() { ... } //This will also not be avalible for
loading.
extern is a whole diffrent creature. extern deals with name
mangling and calling conventions.
extern(C) void foo() { ... }
Uses C name mangling and calling convention:
C name mangling is no name mangling so the symbol for foo() will
simply be foo
All symbols not annotated with an extern will automatically be
extern(D) and wil use the standard D name mangling and calling
convetion.
D name mangling makes this:
module main;
void foo() { ... } into _D4main3fooFZv
This is probably why you did not succeed in loading your test
function.
So to sum up:
export deals with DLL/shared library symbol visibility.
extern(C/D/Windows/C++/Pascal) deals with name mangling and
calling convention.
More information about the Digitalmars-d-learn
mailing list