[libcxx] type_info/bad_cast observations relating to r191397

[G M]

Hi Chandler

On Thu, Oct 3, 2013 at 3:20 AM, Chandler Carruth <chandlerc at google.com>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.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131003/15fa5e76/attachment.html>