[llvm-dev] libcxx build error.

[Eric Fiselier via llvm-dev]

Please send all disscussion about libc++ to cfe-dev.

>  Is libcxx supported on gcc 4.4.7 which comes with CentOS 6.6?

The current documentation for libc++ says that it support GCC 4.2 and
above. However I'm pushing to limit support for GCC 4.7 and beyond in
libc++ (with some pushback).
At this point I think it's reasonable for libc++ to require a compiler
with full C++11 support when using C++11. I don't think GCC 4.4 meets
this requirement. However
I'm still happy to take fixes for older compilers if they are small
and simple enough.

> This looks like something that's not guarded by _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS (after your patch) but should be.
> This one seems fairly easy to fix,

I'm not so sure it's an easy fix because tuple heavily relies on the
compiler to correctly define or delete it's copy/move constructors and
assignment operators. I think that it would be tricky, if not
impossible, to emulate the semantics of the "= default" constructors
using SFINAE for
various reasons.

However we might be able to come up with some sort of workaround for
older GCC's. Could you please submit a bug against libc++?

/Eric

On Sat, Sep 26, 2015 at 8:01 PM, Tim Northover via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
> On 26 September 2015 at 18:45, Srikanth Bemineni via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
>> Is libcxx supported on gcc 4.4.7 which comes with CentOS 6.6. Are LLVM
>> releases very much constrained to the gcc version specified in the software
>> requirements ?
>
> It's probably quite a stretch to say that LLVM 3.4 is still supported
> in any sense. We're not going to release another point fix for it, so
> you're going to be relying on anyone who happens to have a vague
> memory from that era (I don't). As for whether it compiles on CentOS
> 6, apparently not.
>
> Generally we write to the C++ standard, with hacks reluctantly added
> for popular compilers at any given release's time. Releases of CentOS
> and RHEL in long-term support are not usually viewed favourably (they
> tend to be ridiculously ancient).
>
>> I followed the patch mentioned in this link
>> http://comments.gmane.org/gmane.comp.compilers.clang.scm/87139
>
> Thanks for reporting that on the list (honestly), it could be useful
> for others coming along after you at least.
>
>> /home/bemineni/llvm/llvm-3.4.2/projects/libcxx/include/tuple:461: error:
>> ‘std::__1::__tuple_impl<std::__1::__tuple_indices<_Indx ...>, _Tp
>> ...>::__tuple_impl(std::__1::__tuple_impl<std::__1::__tuple_indices<_Indx
>> ...>, _Tp ...>&&)’ cannot be defaulted
>
> This looks like something that's not guarded by
> _LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS (after your patch) but should be.
> This one seems fairly easy to fix, but judging by "grep '= default' |
> wc" vs "grep LIBCPP_... | wc" you might be in for a tedious afternoon
> if you want to fix all instances. If you're lucky, GCC 4.4 will
> support *most* instances of "= default".
>
> Cheers.
>
> Tim.
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev