Repository navigation
error: no member named 'max_align_t' in the global namespace #334
Description
I think this has to do with this issue:
clang-3.5: once gcc-4.9 and g++-4.9 are installed, clang stops properly building existing projects
I tried adding set (CMAKE_C_COMPILER "/usr/bin/clang") to the catch CMakeLists.txt, but it still output this:
In file included from /data/house_data/human_low_copy/tests/general_test.cpp:2:
In file included from /data/house_data/human_low_copy/build/catch/src/catch/include/catch.hpp:28:
In file included from /data/house_data/human_low_copy/build/catch/src/catch/include/internal/catch_capture.hpp:11:
In file included from /data/house_data/human_low_copy/build/catch/src/catch/include/internal/catch_result_builder.h:91:
In file included from /data/house_data/human_low_copy/build/catch/src/catch/include/internal/catch_expression_lhs.hpp:12:
In file included from /data/house_data/human_low_copy/build/catch/src/catch/include/internal/catch_evaluate.hpp:16:
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.9/../../../../include/c++/4.9/cstddef:51:11: error: no member named 'max_align_t' in the global namespace
using ::max_align_t;
~~^
1 error generated.
make[2]: *** [tests/CMakeFiles/general_test.dir/general_test.cpp.o] Error 1
make[1]: *** [tests/CMakeFiles/general_test.dir/all] Error 2
make: *** [all] Error 2
I also change my alternatives (Ubuntu) for gcc / g++ to 4.8 so that gcc --version && g++ --version both return gcc (Ubuntu 4.8.2-19ubuntu1) 4.8.2 and g++ (Ubuntu 4.8.2-19ubuntu1) 4.8.2. But it still pops the error up.
Any idea how to get it to use 4.8? Or how I might solve this problem else-how?
Edit:
Btw, I'm sorry if this is the wrong place for this. I thought you guys might have run into this problem already and therefore know a solution. Plus, I want to have this recorded in the issues so if someone else has the same problem, they know how to fix it.
Activity
danpolanco commentedon Sep 29, 2014
I'm not sure what I changed to fix it, but it is working now. It might have been that I changed clang from 3.4 to 3.5... It's hard to say. If I figure it out, I'll let you all know.
philsquared commentedon Oct 3, 2014
For the record this is not something I've seen before. In any case it doesn't appear to be really a "Catch" thing - although perhaps something about the way Catch includes std lib headers brought it out? The
max_align_tdoes not appear in Catch, at least.Glad you got it sorted, though.
martinmoene commentedon Oct 3, 2014
To give (or get) moral support, I'm experiencing similarly unexpected behaviour from clang/libc++ (at Travis). See lest issue #10.
danpolanco commentedon Oct 3, 2014
What is odd is that I figured out a way to get around it... But it's annoying.
I'm using cmake and it downloads catch on the fly using ExternalProgram_Add as per the instructions. In any case, I call cmake and then make and it works fine for the initial build. Then, if call I cmake and make again without removing all of the files, it throws that error.
So right now, I just
rm -rf *my build folder and then cmake and make again....PureAbstract commentedon Oct 3, 2014
@DanTheColoradan This isn't a Catch issue - it's a compiler/library mismatch issue.
There's no requirement that compiler A be interoperable with compiler B's stdlib implementation, and although the Clang folks certainly go out of their way to ensure their compiler works with gcc's
libstdc++, you've stumbled across a mismatch. I'd recommend usinglibc++with clang, andlibstdc++with gcc.3.11.2 requires that
std::max_align_tis defined, but not that there's a definiton in the global namespace; It seems that the version oflibstdc++that you're using expects it to be defined globally in order to define it instd.That sets CMake's C compiler, not the C++ compiler; you may want to try adding
set(CMAKE_CXX_COMPILER "/usr/bin/clang++")however...
I've seen cases where setting
CMAKE_C_COMPILERandCMAKE_CXX_COMPILERinCMakeLists.txtdoesn't do the right thing (I don't recall the exact details, but ISTR it has something to do with where you set then). As you've found, re-runningcmakein an existingcmaketree isn't quite the same operation as runningcmakein a fresh directory - and I think this may be one of the problem cases.You may want to consider trying:
cmake -DCMAKE_C_COMPILER=/usr/bin/clang -DCMAKE_CXX_COMPILER=/usr/bin/clang++danpolanco commentedon Oct 3, 2014
Thanks! I'll give it a go.
And as I mentioned, I'm definitely not claiming it's a catch issue. I mostly wanted to double check it wasn't, and also leave a record for anyone who stumbles upon this problem.
I'll give your suggestions a thorough testing and leave it at that :)
Thanks again! 👍
philsquared commentedon Oct 3, 2014
Thanks Andy (@PureAbstract) - I missed that the compiler and std libs were being mixed up that way.
Not sure it helps Martin, though
PureAbstract commentedon Oct 3, 2014
@philsquared I think @martinmoene 's actually having a related issue (i.e. travis mixing clang w/libstdc++) - but it can be a bit harder to figure out what's going on with travis :-).
PureAbstract commentedon Oct 3, 2014
@DanTheColoradan Hope it was of some help - the CMake FAQ summarises the CMAKE_CXX_COMPILER issue here - http://www.cmake.org/Wiki/CMake_FAQ#How_do_I_use_a_different_compiler.3F
danpolanco commentedon Oct 3, 2014
It was. I was able to get a little further after reading that documentation, but it was still acting funny. So, I've decided against using clang on linux and I'm just going to use gcc for now. I think that's a better choice anyway since I'll be forced to compile with at least two compilers (i.e. clang on my mac and gcc on linux).
I really appreciate your help.
Edit: by linux I mean Ubuntu ;-)
use libc++ instead of libstdc++ with Clang on Linux
Zmq0max commentedon Jan 4, 2016
@DanTheColoradan You are right. Updating to clang 3.6 fixed it. Thanks
On Linux, build with GCC {4.9,5} and Clang 3.{6,7}