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