DIP45: fixing the dllimport/dllexport issue

Benjamin Thaut code at benjamin-thaut.de
Sun Sep 1 09:43:12 PDT 2013


Am 01.09.2013 17:26, schrieb Rainer Schuetze:
>
>
> On 01.09.2013 11:49, Benjamin Thaut wrote:
>> I updated the DIP with all discussed content. Feedback is welcome.
>>
>> http://wiki.dlang.org/DIP45
>>
>> Kind Regards
>> Benjamin Thaut
>
> LGTM.

Lets get this merged? ^^ First someone has to implement it ;-)

>
> What about the current use case of just exporting some functions for
> being loaded by a C application? It should still work using a def-file
> (which you have to use anyway most of the time due to
> http://d.puremagic.com/issues/show_bug.cgi?id=3956)

Well you can still use a .def file of course. Also no one stops you just 
annotating simple extern(C) functions with the export attribute. I don't 
see any problem there.

>
> Maybe already deep into implementation but how are we going to deal with
> the initialization of data?
>
> module sharedlib;
> __gshared int var;
>
> module exe;
> import sharedlib;
> __gshared int* pvar = &var;
>
> (This kind of relocation also has to be done for stuff like
> TypeInfo_Class). It needs initialization code to fill pvar with the
> correct pointer.

Yes, you are absolutely correct. I don't know enough about the internals 
of a compiler (dmd in perticular) though to answer this question. Can't 
we use the same mechanism C++ uses to run all its initializers?

>
> Do we support the same for pointers in TLS?
>
> int* tlsvar = &var;
>
> This might need initialization per thread, or patching the original TLS
> segment.
>

The DIP has a seperate section on TLS variables. Did you miss to read that?

Kind Regards
Benjamin Thaut


More information about the Digitalmars-d mailing list