<div dir="ltr"><div>Ok I've found at what's going on, it's something like this:</div><div> </div><div>I have this as a param on my cmake command, without it, cmake fails to make the project:</div><div> </div><div>
-DLIBCXX_LIBSUPCXX_INCLUDE_PATHS="/mingw/lib/gcc/x86_64-w64-mingw32/4.8.1/include/c++;/mingw/lib/gcc/x86_64-w64-mingw32/4.8.1/include/c++/x86_64-w64-mingw32" ^<br></div><div> </div><div>That gets fed into /libcxx/cmakelists.txt which has this piece of logic in it:</div>
<div> </div><div>if ("${LIBCXX_CXX_ABI}" STREQUAL "libsupc++")<br> set(_LIBSUPCXX_INCLUDE_FILES<br> cxxabi.h bits/c++config.h bits/os_defines.h bits/cpu_defines.h<br> bits/cxxabi_tweaks.h bits/cxxabi_forced.h<br>
)<br> setup_abi_lib("LIBCXX_LIBSUPCXX_INCLUDE_PATHS" "-D__GLIBCXX__"<br> "supc++" "${_LIBSUPCXX_INCLUDE_FILES}" "bits"<br> )</div><div> </div><div>On my machine, that causes it to find my g++'s bits\c++config.h and copy that into the libcxx_build directory.</div>
<div>and compile. But c++config.h itself defines __GLIBCXX__ right at the start as:</div><div>#define __GLIBCXX__ 20130531</div><div> </div><div>and the setup_abi_lib makes sure the -D__GLIBCXX__ gets also set in ninja.</div>
<div> </div><div>How to unravel that properly to do the right thing (assuming it's not quite right), I'm not sure?</div><div> </div><div>Someone reading this though will remember when they wrote the above logic what it was all about. I remember suggesting a patch to it actually because it didn't copy properly.</div>
<div> </div><div>Assuming we need to remove __GLIBCXX__ here now? From c++config.h? or change the name there or in the -D define above, I'm not sure how cmake is going to do that.or if it should.</div><div> </div><div>
It seems cmakelists.txt needs something changed in it at least. Any ideas?</div><div><br> </div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On Thu, Oct 3, 2013 at 3:20 AM, Chandler Carruth <span dir="ltr"><<a href="mailto:chandlerc@google.com" target="_blank">chandlerc@google.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="im">On Wed, Oct 2, 2013 at 9:10 AM, G M <span dir="ltr"><<a href="mailto:gmisocpp@gmail.com" target="_blank">gmisocpp@gmail.com</a>></span> wrote:<br>
</div><div class="gmail_extra"><div class="gmail_quote"><div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr"><p>Hi Everyone</p><div>Change r191397 affected the libcxx test suite results on my windows machine for g++ and mingw (and possibly eventually VS) builds.</div>
</div></blockquote><div><br></div></div><div>Very sorry for the trouble, and sorry that I missed your original email. Sending stuff to the list as well helps ensure that my filters get me to look at it.</div><div class="im">
<div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
<div dir="ltr"><div><br>The comment is:</div><div>"Make the guard for external ABI libraries include the guard for<br>
libsupc++ in typeinfo.cpp, bringing it into agreement with<br>exception.cpp. This fixes link errors due to duplicate symbols from<br>this translation unit."</div><div> </div><div>I don't know that r191397 is wrong but after applying that change I noticed some additional test suite failures. One example:<br>
c:\libcxx\test\language.support\support.rtti\bad.cast\bad_cast.pass.cpp</div><p>which now results in a linker error where it previously compiled. The linker error is:<br>"undefined reference to std::bad_cast::bad_cast()"</p>
<p>Another test case may be similarly effected is:<br>/libcxx/test/language.support/support.rtti/bad.typeid/bad_typeid.pass.cpp</p><p>Looking at the change, it's because libcxx/src/type_info.cpp was changed from this:<br>
#if !(defined(_LIBCPPABI_VERSION) || defined(LIBCXXRT))</p><p>to this:<br>#if !defined(LIBCXXRT) && !defined(_LIBCPPABI_VERSION) && !defined(__GLIBCXX__)</p><p>and on my builds this now blocks out the definitions for bad_cast and type_info constructors etc. This would account for the linker error, as on my machine LIBCXXRT is not defined && LIBCPPABI_VERSION is not defined either.</p>
</div></blockquote></div><div>Yes, but the critical question is, why was __GLIBCXX__ defined? If it were left undefined, you would still have gotten the symbols.</div><div><br></div><div>That macro is (AFAIK) supposed to indicate that libc++ is being lined with libsupc++, the ABI portion of libstdc++, and thus should not provide these symbols.</div>
<div class="im">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid"><div dir="ltr">
<p>A grep of _LIBCPPABI_VERSION in the libcxx code base shows a few references to other code that may be of interest here.<br>My machine has cxxabi.h which appears possibly also of interest.</p><div>Does anyone know what should be linked in to the above mentioned test cases to restore the bad_cast and type_info definitions for g++/mingw/vs if they are not to be provided by libcxx, so as to make the libcxx test cases compile again?</div>
<div> </div><div>Alternatively if r191397 is incorrect / insufficient, what should be changed in libcxx or the changed guard mentioned above, that will re-enable libcxx to again provide these definitions if it should?</div>
</div></blockquote><div><br></div></div><div>I feel like your build is misconfigured.</div><div><br></div><div>Something needs to provide these pieces of the C++ ABI standard library. Currently, the options are:</div><div>
<br></div>
<div>1) libc++ (what you've been using thus far I suspect)</div><div>2) libsupc++ (from libstdc++, indicated by defining __GLIBCXX__)</div><div>3) libcxxrt (from PathScale, indicated by defining LIBCXXRT)</div><div>4) libc++abi (a sibling project to libc++, indicated by defining _LIBCPPABI_VERSION)</div>
<div><br></div><div>I don't know that #1 is really intended to work long term. I know that Howard indicated to me some users are still relying on this though. I'm personally interested in #2 not breaking (which motivated my change) and in actively supporting #4 as it was developed in close conjunction with libc++. What is your configuration for these pieces of the runtime?</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;padding-left:1ex;border-left-color:rgb(204,204,204);border-left-width:1px;border-left-style:solid">
</blockquote></div><br></div></div>
</blockquote></div><br></div>