Is there is minimum required version for GCC to build LLVM from the head revision?
I have GCC v4.9.3, but ‘Tools/sancov/sancov.cc’ won’t build because ‘std::to_string’ does not exist. When running CMake it did not flag GCC v4.9.3 as too old, and it is passing the ‘-std=gnu++11’ option, but apparently this version of GCC is not fully C++ 11 compliant, or at least its C++ library isn’t.
Everything else builds.
Thanks,
MartinO
Is there is minimum required version for GCC to build LLVM from the head
revision?
Last I checked it was 4.7. The CMake files also tell me that's correct:
modules/CheckCompilerVersion.cmake:
# Check if the host compiler is new enough. LLVM requires at least GCC 4.7,
I have GCC v4.9.3, but ‘Tools/sancov/sancov.cc’ won’t build because
‘std::to_string’ does not exist. When running CMake it did not flag GCC
v4.9.3 as too old, and it is passing the ‘-std=gnu++11’ option, but
apparently this version of GCC is not fully C++ 11 compliant, or at least
its C++ library isn’t.
This sounds odd. I have buildbots with 4.8.2 and 4.9.2 working perfectly.
Could this be a problem in your setup?
cheers,
--renato
I just checked with '-E' and I am picking up '<string>' from:
/usr/lib/gcc/i686-pc/cygwin/4.9.3/include/c++/string
all other C++ headers are coming from the same place. The 'std::to_string' functions are not present in '<string>', but they are located in '<bits/basic_string.h>' - which is included. Perhaps it is a broken Cygwin v4.9.3 package, but this is odd since the source should be identical for the Cygwin versus Linux distros? I can't try this on Linux until tomorrow as I am working from home and don't have a Linux setup that uses v4.9.3.
The 'std::to_string' functions are provided in a block that is conditionally included as follows (line #2847 in my copy):
#if __cplusplus >= 201103L && defined(_GLIBCXX_USE_C99)
#include <ext/string_conversions.h>
namespace std _GLIBCXX_VISIBILITY(default)
{
_GLIBCXX_BEGIN_NAMESPACE_VERSION
The test '__cplusplus >= 201103L' evaluates true in all previous cases, so it would appear that '_GLIBCXX_USE_C99' is not being defined - I can add this explicitly when I am configuring LLVM with CMake, but it seems a bit strange that I need to.
Thanks,
MartinO
Looks like a broken package. I don't know how Cygwin builds their own
packages, but I wouldn't be surprised if they have their own
convoluted build system that hacks stuff together, like every other
distribution. 
We do test it on large number of Linux distributions, on ARM, AArch64
and x86_64, and we have found no problems at all with 4.8 or 4.9.
cheers,
--renato
Sorry for the delay, I had to experiment and build everything to be sure.
I am actually getting the same problem with GCC v4.9.3 on CentOS, but for both Cygwin and Linux adding '-D_GLIBCXX_USE_C99' to the '-DCMAKE_CXX_FLAGS:STRING=' flag during configuration cured the problem.
MartinO
Right, I don't use that flag, why do you need that?
cheers,
--renato
We usually avoid using std::to_string AFAIK because not supported on every platform we support.
Twine or llvm::utostr are good replacements for that, see r267829 or r257857 for instance.
I've no idea, but without it, the 'std::to_string' definitions are not enabled!
That is a useful URL thanks, and the versions of GCC I am using predate the fix in the ticket.
Curious though, because both Linux and Cygwin are building LLVM using the host configuration, and both provide a full 'glibc' implementation. This could be a CMake/Cygwin problem that I am experiencing - I had to build CMake v3.5.2 from source using the usual 'configure/make/install' process, but it is not an official build from either Kitware (not available) or from the Cygwin distribution (too old).
I did try to build LLVM at revision #272991 on Linux (CentOS) but our setup has GCC v4.8.5 20150623 and not v4.9.3 as I previously thought. It did not get as far as building 'sancov.cc' though, and died with:
[ 57%] Copying clang's immintrin.h...
make[4]: *** No rule to make target `/work/dub44/martino/WORK/Compilers/llvmHead/llvm/tools/clang/lib/Headers/intrin.h', needed by `lib/clang/3.9.0/include/intrin.h'. Stop.
I haven't investigated this yet, but it is quite likely that the snapshot I took at revision #272991 was not yet BuildBot clean, so I will update to the head revision tomorrow and merge over the weekend and try again.
Thanks,
MartinO