<div dir="ltr"><div><div>The same thing apply to static libc++ on Windows and when cross compiling to Windows.<br><br></div>Martell told me about his patch for this bug [0] and while it works the same as passing mentioned flag to CC1 it looks better.<br></div>Any chances for accepting it soon?<br><br>[0] <a href="https://reviews.llvm.org/D33620">https://reviews.llvm.org/D33620</a><div><div><div><div><div class="gmail_extra"><br><div class="gmail_quote">2017-09-19 14:35 GMT+02:00 Mateusz Mikuła <span dir="ltr"><<a href="mailto:mati865@gmail.com" target="_blank">mati865@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div><div>This is what I've got for MSYS2 [0] and looks like there are no regressions but I couldn't get `make check` to run (multiple definition errors in LLVM).</div><div><br></div><div>I haven't tested this patch on Ubuntu but adding `-flto-visibility-public-std` to CC1 solves this issue [1] so I belive  will help there.</div><div><br></div><div>Instead of reverting dllimport changes final solution could be similar to this patch but probably it would require writing some tests but I doubt I'll have time to learn how to do it with clang soon.</div><div><br></div><div><br></div><div>[0] <a href="https://github.com/mati865/MINGW-packages/blob/954fa97c5349029b75b63c58ae81c62a39fa9658/mingw-w64-clang/0106-MinGW-use-flto-visibility-public-std-CC1-arg-to-get-.patch" target="_blank">https://github.com/mati865/<wbr>MINGW-packages/blob/<wbr>954fa97c5349029b75b63c58ae81c6<wbr>2a39fa9658/mingw-w64-clang/<wbr>0106-MinGW-use-flto-<wbr>visibility-public-std-CC1-arg-<wbr>to-get-.patch</a></div><div>[1] <a href="https://bugs.llvm.org/show_bug.cgi?id=34122" target="_blank">https://bugs.llvm.org/show_<wbr>bug.cgi?id=34122</a></div><div><div class="gmail-h5"><div><br></div><div>W dniu nie, 17.09.2017 o godzinie 09∶49 -0700, użytkownik Saleem Abdulrasool napisał:</div><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex"><div dir="ltr">I think that making it conditional to Windows and not the MSVC ABI and a static link to the C++ runtime sounds reasonable.<br><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Sep 17, 2017 at 4:40 AM, Mateusz Mikuła <span dir="ltr"><<a href="mailto:mati865@gmail.com" target="_blank">mati865@gmail.com</a>></span> wrote:<br><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex">
  
    
  
  <div bgcolor="#FFFFFF"><span>
    <div id="gmail-m_8598650107188862167m_7556011901451495183smartTemplate4-template">
      <div id="gmail-m_8598650107188862167m_7556011901451495183smartTemplate4-template">
        <p>Sorry Saleem, looks like this topic got lost on my TODO.<br>
        </p>
      </div>
      Adding `-flto-visibility-public-std` to CC1 helps with undefined
      reference to `_imp___cxa*` errors.<br>
      <br>
      Is it safe enough to make it default flag for MSYS2?<br>
      If so I'll patch clang to use it by default.</div>
    <br>
    <br>
    <div id="gmail-m_8598650107188862167m_7556011901451495183smartTemplate4-quoteHeader">------ Original Message ------<br>
      Subject: Re: [cfe-dev] [MinGW] Clang issues with static libstdc++<br>
      Date: Mon, 26 Jun 2017 21:51:19 -0700<br>
      To: Mateusz Mikuła, Reid Kleckner, Cfe-dev<br>
      From: Saleem Abdulrasool</div>
    </span><blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex">
      <div dir="ltr">
        <div class="gmail_extra">Building with
          `-flto-visibility-public-std` should allow the static build to
          work.  I think that having support for a static c++ library
          makes sense, but need to expose it through a flag to have it
          behave like `/MT` vs `/MD`.</div><div><div class="gmail-m_8598650107188862167h5">
        <div class="gmail_extra"><br>
        </div>
        <div class="gmail_extra">There is a small performance cost for
          the thunks, plus binary size benefits for very large binaries
          (especially with the BFD linker).  IIRC, some versions of lldb
          also had trouble with the import thunks when generated by the
          BFD linker.  I would rather have this be the default and have
          an opt-out mechanism rather than the inverse (a la
          `-fno-plt`).</div>
        <div class="gmail_extra"><br>
          <div class="gmail_quote">On Sun, Jun 25, 2017 at 1:20 PM,
            Mateusz Mikuła <span dir="ltr"><<a href="mailto:mati865@gmail.com" target="_blank">mati865@gmail.com</a>></span>
            wrote:<br>
            <blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex">
              <div>
                <div>I've been quite busy lately and lost track on
                  recent fixes.</div>
                <div>Is there any progress on this or should I apply for
                  bugzilla account and forward it there?</div>
                <div>
                  <div class="gmail-m_8598650107188862167m_7556011901451495183h5">
                    <div><br>
                    </div>
                    <div>On Mon, 2017-04-17 at 11∶56 -0700, Reid
                      Kleckner wrote:</div>
                    <blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex">
                      <div dir="ltr">The __imp___cxa_begin_catch error
                        seems related to this code in CodeGenModule::CreateRuntim<wbr>eFunction:
                        <div>
                          <div>      if (!Local &&
                            getTriple().isOSBinFormatCOFF(<wbr>)
                            &&</div>
                          <div>          !getCodeGenOpts().LTOVisibilit<wbr>yPublicStd)
                            {</div>
                          <div>        const FunctionDecl *FD =
                            GetRuntimeFunctionDecl(Context<wbr>, Name);</div>
                          <div>        if (!FD ||
                            FD->hasAttr<DLLImportAttr>()) {</div>
                          <div>          F->setDLLStorageClass(llvm::Gl<wbr>obalValue::DLLImportStorageCla<wbr>ss);</div>
                          <div>          F->setLinkage(llvm::GlobalValu<wbr>e::ExternalLinkage);</div>
                          <div>        }</div>
                          <div>      }</div>
                        </div>
                        <div><br>
                        </div>
                        <div>This code assumes that all
                          compiler-referenced runtime functions on COFF
                          are dllimport, unless we happen to see a
                          prototype for them during compilation that
                          says otherwise. Saleem felt we shouldn't rely
                          on the import thunks that the linker generates
                          when you reference an imported function but
                          forget to declare it as dllimport during
                          compilation. It has some performance benefits,
                          but it never really bothered me. Most users
                          don't complain about the extra absolute branch
                          imposed by the PLT on ELF, and those that do
                          are getting -fno-plt soon.</div>
                        <div><br>
                        </div>
                        <div>Anyway, you can see the code difference
                          easily here:</div>
                        <div><br>
                        </div>
                        <div>
                          <div>$ cat t.cpp</div>
                          <div>void g();</div>
                          <div>void f() {</div>
                          <div>  try {</div>
                          <div>    g();</div>
                          <div>  } catch (...) {</div>
                          <div>  }</div>
                          <div>}</div>
                          <div><br>
                          </div>
                          <div>$ clang -O1 -S t.cpp
                            --target=x86_64-windows-gnu -o - | grep
                            __cxa</div>
                          <div>        callq  
                            *__imp___cxa_begin_catch(%rip)</div>
                          <div>        rex64 jmpq    
                             *__imp___cxa_end_catch(%rip) # TAILCALL</div>
                          <div><br>
                          </div>
                          <div>$ gcc -O1 -S t.cpp -o - | grep __cxa</div>
                          <div>        call    __cxa_begin_catch</div>
                          <div>        call    __cxa_end_catch</div>
                          <div>        .def    __cxa_begin_catch;    
                             .scl    2;      .type   32;     .endef</div>
                          <div>        .def    __cxa_end_catch;      
                             .scl    2;      .type   32;     .endef</div>
                        </div>
                        <div><br>
                        </div>
                        <div>The other error looks like some kind of
                          COMDAT disagreement between GCC and Clang that
                          will require further investigation. It might
                          relate to our choice to stop using
                          ".text$function_name" for the section.</div>
                      </div>
                      <div class="gmail_extra"><br>
                        <div class="gmail_quote">On Mon, Apr 17, 2017 at
                          11:06 AM, Mateusz Mikuła via cfe-dev <span dir="ltr"><<a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a>></span>
                          wrote:<br>
                          <blockquote type="cite" style="margin:0px 0px 0px 0.8ex;border-left:2px solid rgb(114,159,207);padding-left:1ex">
                            <div bgcolor="#FFFFFF">
                              <p>Clang doesn't work very well with
                                static libstdc++ build for MinGW
                                resulting in "multiple definition ..."
                                or "undefined reference" to the symbols.<br>
                              </p>
                              <p>Let's consider following code (removed
                                includes and main for readability):</p>
                              <ol>
                                <li>multiple definition:<br>
                                  <br>
                                  <div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Consolas,"Courier New",monospace;font-weight:normal;font-size:14px;line-height:19px;white-space:pre-wrap"><div><span style="color:rgb(212,212,212)">    std::string a = </span><span style="color:rgb(206,145,120)">"a"</span><span style="color:rgb(212,212,212)">;</span></div><div><span style="color:rgb(212,212,212)">    std::string b = </span><span style="color:rgb(206,145,120)">'@'</span><span style="color:rgb(212,212,212)"> + a;</span></div></div>
                                  <br>
                                  This simple code build with `-static`
                                  flag will cause this error:<br>
                                  <br>
                                  D:\msys64\mingw64\lib\gcc\x86_<wbr>64-w64-mingw32\6.3.0\libstdc++<wbr>.a(string-inst.o):(.text$_ZStp<wbr>lIcSt11char_traitsIcESaIcEENSt<wbr>7__cxx1112basic_stringIT_T0_T1<wbr>_EES5_RKS8_[_ZStplIcSt11char_t<wbr>raitsIcESaIcEENSt7__cxx1112bas<wbr>ic_stringIT_T0_T1_EES5_RKS8_]+<wbr>0x0):
                                  multiple definition of
                                  `std::__cxx11::basic_string<ch<wbr>ar,
                                  std::char_traits<char>,
                                  std::allocator<char> >
                                  std::operator+<char,
                                  std::char_traits<char>,
                                  std::allocator<char> >(char,
                                  std::__cxx11::basic_string<cha<wbr>r,
                                  std::char_traits<char>,
                                  std::allocator<char> >
                                  const&)'<br>
                                  D:\msys64\tmp\string-e39e30.o:<wbr>(.text[_ZStplIcSt11char_traits<wbr>IcESaIcEENSt7__cxx1112basic_st<wbr>ringIT_T0_T1_EES5_RKS8_]+0x0):
                                  first defined here<br>
                                  clang++.exe: error: linker command
                                  failed with exit code 1 (use -v to see
                                  invocation)<br>
                                  <br>
                                </li>
                                <li>undefined reference<br>
                                  <br>
                                  <div style="color:rgb(212,212,212);background-color:rgb(30,30,30);font-family:Consolas,"Courier New",monospace;font-weight:normal;font-size:14px;line-height:19px;white-space:pre-wrap"><div><span style="color:rgb(212,212,212)">    std::u16string b;</span></div></div>
                                  <br>
                                  This time adding `-static` to clang
                                  arguments will cause this error (note:
                                  `__imp___cxa_call_unexpected` exists
                                  only in dynamic libstdc++):<br>
                                  <br>
                                  D:\msys64\tmp\string-7062fd.o:<wbr>(.text[_ZNSt7__cxx1112basic_st<wbr>ringIDsSt11char_traitsIDsESaID<wbr>sEED2Ev]+0x4a):
                                  undefined reference to
                                  `__imp___cxa_call_unexpected'<br>
                                  D:\msys64\tmp\string-7062fd.o:<wbr>(.text[__clang_call_terminate]<wbr>+0x7):
                                  undefined reference to
                                  `__imp___cxa_begin_catch'<br>
                                  D:\msys64\tmp\string-7062fd.o:<wbr>(.text[_ZNSt7__cxx1112basic_st<wbr>ringIDsSt11char_traitsIDsESaID<wbr>sEE10_M_destroyEy]+0x72):
                                  undefined reference to
                                  `__imp___cxa_call_unexpected'<br>
                                  clang++.exe: error: linker command
                                  failed with exit code 1 (use -v to see
                                  invocation)<br>
                                  <br>
                                </li>
                              </ol>
                              <p>It is probably related to the way the
                                symbols are build into static libstdc++
                                for MinGW.<br>
                                Let's take a look at weak symbol from
                                different test cases:</p>
                              <ol>
                                <li>MinGW, dynamic libstdc++:<br>
                                  0000000000000000 I
                                  __imp__ZNSt7__cxx1112basic_str<wbr>ingIcSt11char_traitsIcESaIcEE1<wbr>2_M_constructIPKcEEvT_S8_St20f<wbr>orward_iterator_tag<br>
                                  0000000000000000 T
                                  _ZNSt7__cxx1112basic_stringIcS<wbr>t11char_traitsIcESaIcEE12_M_co<wbr>nstructIPKcEEvT_S8_St20forward<wbr>_iterator_tag<br>
                                  <br>
                                </li>
                                <li>MinGW, static libstdc++:<br>
                                  0000000000000000 p
                                  .pdata$_ZNSt7__cxx1112basic_st<wbr>ringIcSt11char_traitsIcESaIcEE<wbr>12_M_constructIPKcEEvT_S8_St20<wbr>forward_iterator_tag<br>
                                  0000000000000000 t
                                  .text$_ZNSt7__cxx1112basic_str<wbr>ingIcSt11char_traitsIcESaIcEE1<wbr>2_M_constructIPKcEEvT_S8_St20f<wbr>orward_iterator_tag<br>
                                  0000000000000000 r
                                  .xdata$_ZNSt7__cxx1112basic_st<wbr>ringIcSt11char_traitsIcESaIcEE<wbr>12_M_constructIPKcEEvT_S8_St20<wbr>forward_iterator_tag<br>
                                  0000000000000000 T
                                  _ZNSt7__cxx1112basic_stringIcS<wbr>t11char_traitsIcESaIcEE12_M_co<wbr>nstructIPKcEEvT_S8_St20forward<wbr>_iterator_tag<br>
                                  <br>
                                </li>
                                <li>Linux, static libstdc++:<br>
                                  0000000000000000 W
                                  _ZNSt7__cxx1112basic_stringIcS<wbr>t11char_traitsIcESaIcEE12_M_co<wbr>nstructIPKcEEvT_S8_St20forward<wbr>_iterator_tag</li>
                              </ol>
                              <p>This greatly reduces Clang usefulness
                                on Windows with MinGW.<br>
                                All responses are welcome.</p>
                              <p>Best Regards,<br>
                                Mateusz<br>
                              </p>
                            </div>
                            <br>
                            ______________________________<wbr>_________________<br>
                            cfe-dev mailing list<br>
                            <a href="mailto:cfe-dev@lists.llvm.org" target="_blank">cfe-dev@lists.llvm.org</a><br>
                            <a href="http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-dev" rel="noreferrer" target="_blank">http://lists.llvm.org/cgi-bin/<wbr>mailman/listinfo/cfe-dev</a><br>
                            <br>
                          </blockquote>
                        </div>
                        <br>
                      </div>
                    </blockquote>
                  </div>
                </div>
              </div>
            <br></blockquote>
          </div>
          <br>
          <br clear="all">
          <div><br>
          </div>
          -- <br>
          <div class="gmail-m_8598650107188862167m_7556011901451495183gmail_signature">Saleem
            Abdulrasool<br>
            compnerd (at) compnerd (dot) org</div>
        </div>
      </div></div></div>
    </blockquote>
    <br>
  </div>

</blockquote></div><br><br clear="all"><div><br></div></div></div></blockquote></div></div></div></blockquote></div><br></div></div></div></div></div></div>