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