I will try that in a few hours when I'm back from work. Am 06.09.2011 08:16, schrieb Walter Bright: > Could you get the druntime sources for the last dmd release, try > those, and see if it works successfully? > > On 9/5/2011 10:52 PM, Sönke Ludwig wrote: >> Am 05.09.2011 23:53, schrieb Rainer Schuetze: >>> On 05.09.2011 21:35, Sönke Ludwig wrote: >>>> Am 05.09.2011 19:54, schrieb Rainer Schuetze: >>>>> >>>>> What OS are you running on? >>>>> >>>>> Your code works for me (XP SP3). Also Visual D works fine AFAICT >>>>> (its a plugin DLL to VS). >>>>> >>>> Windows 7 x64 SP1... But it is more complicated than it seemed. >>>> >>>> I had another file linked to the DLL that I thought had not effect. >>>> But actually it used a function from another DLL* that was linked >>>> in statically via passing a .lib file to the command line (along >>>> with the source files). The error does not occur if compiling and >>>> linking is done by separate invocations of dmd. Also commenting out >>>> all the lines that use a function from the external DLL fixes the >>>> problem. >>>> >>>> (* that DLL is LLVM 2.9, so no D code inside) >>>> >>>> >>> >>> There might be issues if you are calling another DLL from inside the >>> (non-shared) static constructors and that DLL also uses TLS. In >>> DllMain(DLL_PROCESS_ATTACH), each existing thread is initialized by >>> just swapping the TLS data of the DLL and then running the module >>> initialization. So if another DLL is called, it will only see the >>> TLS of the thread that called DllMain. >>> >>> I don't think anything in this code has changes recently. Is this a >>> regression from the last dmd version? >>> >>> >>> >>> >>> _______________________________________________ >>> dmd-beta mailing list >>> [email protected] >>> http://lists.puremagic.com/mailman/listinfo/dmd-beta >> Yes, it is a regression in the first beta. The new beta also has it. >> >> In general, the LLVM DLL was not called at all before the error >> occurs, the pure fact that there was a dependency to it somewhere in >> the code causes the problem. Also, it doesn't matter whether the >> array is used somwhere inside of DllMain or later from within an >> exported function (this was actually the case before I tried to strip >> it down). There is just one static constructor in the code. >> Commenting it out does not affect the problem. >> >> I now completely removed any other code and just put in one function >> call after the array appending line. Commenting out the llvm call >> will cause the array to be correctly initialized/referenced, >> otherwise it contains garbage in its ptr/length fields. (making it >> __gshared also fixes it) >> >> The llvm.lib containing the llvm functions was generated from the dll >> using implib. >> >> --- >> import std.c.windows.windows; >> import core.sys.windows.dll; >> >> import llvm.target; >> int[] test; >> >> extern (Windows) >> BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID pvReserved) >> { >> switch (ulReason) { >> default: return false; >> case DLL_PROCESS_ATTACH: >> if( !dll_process_attach( hInstance, true ) ) return false; >> test ~= 1; // throws out of memory >> LLVMInitializeX86TargetInfo(); // commenting out this >> will make it work >> break; >> case DLL_PROCESS_DETACH: dll_process_detach( hInstance, true >> ); break; >> case DLL_THREAD_ATTACH: dll_thread_attach( true, true ); break; >> case DLL_THREAD_DETACH: dll_thread_detach( true, true ); break; >> } >> return true; >> } >> --- >> >> >> _______________________________________________ >> dmd-beta mailing list >> [email protected] >> http://lists.puremagic.com/mailman/listinfo/dmd-beta > > > _______________________________________________ > dmd-beta mailing list > [email protected] > http://lists.puremagic.com/mailman/listinfo/dmd-beta
_______________________________________________ dmd-beta mailing list [email protected] http://lists.puremagic.com/mailman/listinfo/dmd-beta
