Hi Chandler On Thu, Oct 3, 2013 at 3:20 AM, Chandler Carruth <[email protected]>wrote:
> Yes, but the critical question is, why was __GLIBCXX__ defined? If it were > left undefined, you would still have gotten the symbols. > > 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. > >> A grep of _LIBCPPABI_VERSION in the libcxx code base shows a few >> references to other code that may be of interest here. >> My machine has cxxabi.h which appears possibly also of interest. >> 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? >> >> 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? >> > > I feel like your build is misconfigured. > Yes you are right! (I think), I discovered why. See below. > > Something needs to provide these pieces of the C++ ABI standard library. > Currently, the options are: > > 1) libc++ (what you've been using thus far I suspect) > 2) libsupc++ (from libstdc++, indicated by defining __GLIBCXX__) > 3) libcxxrt (from PathScale, indicated by defining LIBCXXRT) > 4) libc++abi (a sibling project to libc++, indicated by defining > _LIBCPPABI_VERSION) > > 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? > >> > > 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. When I do cd \libcxx_build cmake -G "Ninja" c:/libcxx etc. and I look at the build.ninja file in c:\libcxx_build, and I see lines like this: DEFINES = -D_DEBUG -D_LIBCPP_BUILD_STATIC -D__GLIBCXX__ I tried removing the __GLIBCXX_ references from the build.ninja file (they aren't in rules.ninja) but when I do: cd \libcxx_build ninja 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. 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. This looks like a bug in cmake perhaps? 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? 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. 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? 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.
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
