<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    It's getting more interesting... it works fine if the DLL is loaded
    from a D application - loading it from a C++ application (compiled
    with MSVS 2010) will fail with the exception.<br>
    <br>
    I've uploaded a zip file [1] with the dllmain and the LLVM DLL, a D
    test program and the failing C++ project for VS 2010.<br>
    <br>
    The build.cmd builds the DLL and the D test project using equivalent
    flags as for the full project, although the flags do not seem to
    matter.<br>
    <br>
    I will try to see if the LLVM DLL can somehow be ruled out of the
    equation when I get some time later.<br>
    <br>
    [1] <a href="http://netload.in/dateiuknS5rMdiL/linkproblem.zip.htm"
      target="_blank">http://netload.in/dateiuknS5rMdiL/linkproblem.zip.htm</a><br>
    <br>
    <br>
    Am 06.09.2011 09:14, schrieb Rainer Schuetze:
    <blockquote cite="mid:4E65C871.5090608@gmx.de" type="cite">
      <meta content="text/html; charset=ISO-8859-1"
        http-equiv="Content-Type">
      <br>
      With the call LLVMInitializeX86TargetInfo, the llvm DLL will be
      initialized before DllMain of your DLL is called. I could not find
      a matching DLL in the LLVM binary distribution. I guess you have
      built it yourself. Could you provide it for download somewhere?<br>
      <br>
      On 06.09.2011 07:52, Sönke Ludwig wrote:
      <blockquote cite="mid:4E65B527.2010503@informatik.uni-luebeck.de"
        type="cite">
        <meta content="text/html; charset=ISO-8859-1"
          http-equiv="Content-Type">
        Am 05.09.2011 23:53, schrieb Rainer Schuetze:
        <blockquote cite="mid:4E6544EC.1080204@gmx.de" type="cite">
          <meta content="text/html; charset=ISO-8859-1"
            http-equiv="Content-Type">
          On 05.09.2011 21:35, Sönke Ludwig wrote:
          <blockquote
            cite="mid:4E65247F.2090705@informatik.uni-luebeck.de"
            type="cite">
            <meta content="text/html; charset=ISO-8859-1"
              http-equiv="Content-Type">
            Am 05.09.2011 19:54, schrieb Rainer Schuetze:
            <blockquote cite="mid:4E650CBA.6080702@gmx.de" type="cite">
              <meta content="text/html; charset=ISO-8859-1"
                http-equiv="Content-Type">
              <br>
              What OS are you running on? <br>
              <br>
              Your code works for me (XP SP3). Also Visual D works fine
              AFAICT (its a plugin DLL to VS).<br>
              <br>
            </blockquote>
            Windows 7 x64 SP1... But it is more complicated than it
            seemed.<br>
            <br>
            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.<br>
            <br>
            (* that DLL is LLVM 2.9, so no D code inside)<br>
            <br>
            <br>
          </blockquote>
          <br>
          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.<br>
          <br>
          I don't think anything in this code has changes recently. Is
          this a regression from the last dmd version?<br>
          <br>
          <br>
          <br>
          <fieldset class="mimeAttachmentHeader"></fieldset>
          <br>
          <pre wrap="">_______________________________________________
dmd-beta mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:dmd-beta@puremagic.com">dmd-beta@puremagic.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/dmd-beta">http://lists.puremagic.com/mailman/listinfo/dmd-beta</a></pre>
        </blockquote>
        Yes, it is a regression in the first beta. The new beta also has
        it.<br>
        <br>
        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.<br>
        <br>
        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)<br>
        <br>
        The llvm.lib containing the llvm functions was generated from
        the dll using implib.<br>
        <br>
        ---<br>
        import std.c.windows.windows;<br>
        import core.sys.windows.dll;<br>
        <br>
        import llvm.target;<br>
        int[] test;<br>
        <br>
        extern (Windows)<br>
        BOOL DllMain(HINSTANCE hInstance, ULONG ulReason, LPVOID
        pvReserved) <br>
        { <br>
            switch (ulReason) {<br>
                default: return false;<br>
                case DLL_PROCESS_ATTACH:<br>
                    if( !dll_process_attach( hInstance, true ) ) return
        false;<br>
                    test ~= 1; // throws out of memory<br>
                    LLVMInitializeX86TargetInfo(); // commenting out
        this will make it work<br>
                    break;<br>
                case DLL_PROCESS_DETACH: dll_process_detach( hInstance,
        true ); break;<br>
                case DLL_THREAD_ATTACH: dll_thread_attach( true, true );
        break;<br>
                case DLL_THREAD_DETACH: dll_thread_detach( true, true );
        break;<br>
            }<br>
            return true;<br>
        }<br>
        ---<br>
        <br>
        <fieldset class="mimeAttachmentHeader"></fieldset>
        <br>
        <pre wrap="">_______________________________________________
dmd-beta mailing list
<a moz-do-not-send="true" class="moz-txt-link-abbreviated" href="mailto:dmd-beta@puremagic.com">dmd-beta@puremagic.com</a>
<a moz-do-not-send="true" class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/dmd-beta">http://lists.puremagic.com/mailman/listinfo/dmd-beta</a></pre>
      </blockquote>
      <br>
      <br>
      <fieldset class="mimeAttachmentHeader"></fieldset>
      <br>
      <pre wrap="">_______________________________________________
dmd-beta mailing list
<a class="moz-txt-link-abbreviated" href="mailto:dmd-beta@puremagic.com">dmd-beta@puremagic.com</a>
<a class="moz-txt-link-freetext" href="http://lists.puremagic.com/mailman/listinfo/dmd-beta">http://lists.puremagic.com/mailman/listinfo/dmd-beta</a></pre>
    </blockquote>
    <br>
  </body>
</html>