[libcxx] type_info/bad_cast observations relating to r191397

[G M]

Ok I've found at what's going on, it's something like this:

I have this as a param on my cmake command, without it, cmake fails to make
the project:

-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"
^

That gets fed into /libcxx/cmakelists.txt which has this piece of logic in
it:

if ("${LIBCXX_CXX_ABI}" STREQUAL "libsupc++")
  set(_LIBSUPCXX_INCLUDE_FILES
    cxxabi.h bits/c++config.h bits/os_defines.h bits/cpu_defines.h
    bits/cxxabi_tweaks.h bits/cxxabi_forced.h
    )
  setup_abi_lib("LIBCXX_LIBSUPCXX_INCLUDE_PATHS" "-D__GLIBCXX__"
    "supc++" "${_LIBSUPCXX_INCLUDE_FILES}" "bits"
    )

On my machine, that causes it to find my g++'s bits\c++config.h and copy
that into the libcxx_build directory.
and compile. But c++config.h itself defines __GLIBCXX__ right at the start
as:
#define __GLIBCXX__ 20130531

and the setup_abi_lib makes sure the -D__GLIBCXX__ gets also set in ninja.

How to unravel that properly to do the right thing (assuming it's not quite
right), I'm not sure?

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.

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.

It seems cmakelists.txt needs something changed in it at least. Any ideas?




On Thu, Oct 3, 2013 at 3:20 AM, Chandler Carruth <chandlerc at google.com>wrote:

> On Wed, Oct 2, 2013 at 9:10 AM, G M <gmisocpp at gmail.com> wrote:
>
>> Hi Everyone
>> Change r191397 affected the libcxx test suite results on my
>> windows machine for g++ and mingw (and possibly eventually VS) builds.
>>
>
> 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.
>
>
>>
>> The comment is:
>> "Make the guard for external ABI libraries include the guard for
>>  libsupc++ in typeinfo.cpp, bringing it into agreement with
>> exception.cpp. This fixes link errors due to duplicate symbols from
>> this translation unit."
>>
>> I don't know that r191397 is wrong but after applying that change I
>> noticed some additional test suite failures. One example:
>> c:\libcxx\test\language.support\support.rtti\bad.cast\bad_cast.pass.cpp
>>
>> which now results in a linker error where it previously compiled. The
>> linker error is:
>> "undefined reference to std::bad_cast::bad_cast()"
>>
>> Another test case may be similarly effected is:
>> /libcxx/test/language.support/support.rtti/bad.typeid/bad_typeid.pass.cpp
>>
>> Looking at the change, it's because libcxx/src/type_info.cpp was changed
>> from this:
>> #if !(defined(_LIBCPPABI_VERSION) || defined(LIBCXXRT))
>>
>> to this:
>> #if !defined(LIBCXXRT) && !defined(_LIBCPPABI_VERSION) &&
>> !defined(__GLIBCXX__)
>>
>> 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.
>>
> 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.
>
> 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?
>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131003/1758adfe/attachment.html>