<div dir="ltr"><div class="gmail_extra">Hi Chandler<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: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 class="im">Yes, but the critical question is, why was __GLIBCXX__ defined? If it were left undefined, you would still have gotten the symbols. </div>
</div></blockquote><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 class="gmail_extra">
<div class="gmail_quote"><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></div></div></blockquote><div> </div><div>Yes you are right! (I think), I discovered why. See below. </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 class="gmail_extra"><div class="gmail_quote"><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></div></div></blockquote><div> </div>
<div>I build with cmake and ninja and I think it's cmake that is causing the __GLIBCXX__ definition to get in but it's hard to see where.</div><div> </div><div>When I do</div><div>cd \libcxx_build</div><div>cmake -G "Ninja" c:/libcxx etc.</div>
<div> </div><div>and I look at the build.ninja file in c:\libcxx_build, and I see lines like this:</div><div> </div><div>  DEFINES = -D_DEBUG -D_LIBCPP_BUILD_STATIC -D__GLIBCXX__</div><div> </div><div>I tried removing the __GLIBCXX_ references from the build.ninja file (they aren't in rules.ninja)  but when I do:</div>
<div>cd \libcxx_build</div><div>ninja</div><div> </div><div>The weirdest thing is all the compiler instances started by ninja all report __GLIBCXX__ as defined even when I remove it manually from the file. I thought I had deleted all the temp files it could read.</div>
<div> </div><div>But when I compile from the same command line using clang++ directly and not cmake or ninja, __GLIBCXX__ isn't reported as being defined but when ninja starts the compiler suddenly it's __GLIBCXX__ is back defined.</div>
<div> </div><div>This looks like a bug in cmake perhaps?</div><div> </div><div>I'm pretty sure it's cmake or a file that is being fed into cmake that is causing this. But which one and where?</div><div> </div><div>
Unfortunately I can't get findstr and grep to search into sub directories or find properly at least, and I have no idea why that is, so I can't find where this is __GLIBCXX__ is getting defined.</div><div> </div><div>
But it's got to be an input file to cmake or an output from cmake, but where else? Quite why cmake is causing __GLIBCXX__ to go in build.ninja I don't know, but it's got the idea from somewhere but where?</div>
<div> </div><div>I'll keep looking into it. Thanks for your help, you are right that it's definitely that __GLIBCXX__ that is getting defined somehow that I don't understand that is causing the problem.<br></div>
</div></div></div>