libcxx build error.

Hi,

I am trying to build llvm 3.4.2 on Centos 6.6. I am getting this below build error , while building the libcxx. I followed the build procedure based of http://clang.llvm.org/get_started.html. I cannot move to a higher version, Since we need to develop on CentOS 6.6 and LLVM 3.4.2 ,is the last version that supports gcc 3.4.2. Starting from LLVM 3.5.0, there has been a huge jump to gcc 4.7.0.

I am just starting to get acquainted to LLVM. So please bare with my questions.

Linking CXX executable …/…/bin/not
[ 52%] Built target not
Scanning dependencies of target yaml-bench
[ 52%] Building CXX object utils/yaml-bench/CMakeFiles/yaml-bench.dir/YAMLBench.cpp.o
Linking CXX executable …/…/bin/yaml-bench
[ 52%] Built target yaml-bench
Scanning dependencies of target cxx
[ 52%] Building CXX object projects/libcxx-3.4.2/lib/CMakeFiles/cxx.dir/__/src/string.cpp.o
In file included from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/algorithm:624,
from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/string:439,
from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/src/string.cpp:12:
/home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/type_traits:3280: error: expected primary-expression before ‘decltype’
/home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/type_traits:3280: error: expected ‘;’ before ‘decltype’
In file included from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/algorithm:626,
from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/string:439,
from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/src/string.cpp:12:
/home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/utility:320: error: ‘std::__1::pair<_T1, _T2>::pair(std::__1::pair<_T1, _T2>&&)’ cannot be defaulted
In file included from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/memory:603,
from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/algorithm:627,
from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/include/string:439,
from /home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/src/string.cpp:12:
/home/bemineni/llvm/llvm-3.4.2/projects/libcxx-3.4.2/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
make[2]: *** [projects/libcxx-3.4.2/lib/CMakeFiles/cxx.dir/
/src/string.cpp.o] Error 1
make[1]: *** [projects/libcxx-3.4.2/lib/CMakeFiles/cxx.dir/all] Error 2
make: *** [all] Error 2

With Regards

Srikanth Bemineni

Hi,

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 ?

I followed the patch mentioned in this link http://comments.gmane.org/gmane.comp.compilers.clang.scm/87139

Index: include/__config

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.

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