Pathscale compiler also pretends to be GCC and doesn't support tr1/tuple
Closed this issue · 1 comments
GoogleCodeExporter commented
The gtest-port.h header has this bit in it:
// We use our own TR1 tuple if we aren't sure the user has an
// implementation of it already. At this time, GCC 4.0.0+ and MSVC
// 2010 are the only mainstream compilers that come with a TR1 tuple
// implementation. NVIDIA's CUDA NVCC compiler pretends to be GCC by
// defining __GNUC__ and friends, but cannot compile GCC's tuple
// implementation. MSVC 2008 (9.0) provides TR1 tuple in a 323 MB
// Feature Pack download, which we cannot assume the user has.
# if (defined(__GNUC__) && !defined(__CUDACC__) && (GTEST_GCC_VER_ >= 40000)) \
|| _MSC_VER >= 1600
# define GTEST_USE_OWN_TR1_TUPLE 0
# else
# define GTEST_USE_OWN_TR1_TUPLE 1
# endif
Unfortunately, when compiling with the Pathscale compiler
(https://github.com/pathscale/path64-suite), this doesn't work, because it does
something similar to what Cuda does.
I simply added another !defined(__PATHCC__) in there, and then it seems to work.
(There is still a problem with the compiler not recognizing -Wextra, but I'm
not sure how to patch that out except by removing that line from
cmake/internal_utils.cmake. I guess Cmake may be mis-identifying the compiler?)
Original issue reported on code.google.com by eva...@gmail.com
on 20 Feb 2012 at 7:47
GoogleCodeExporter commented
The downsides of fixing this is the increased code complexity and the fragility
of the approach (if/when Pathscale starts supporting tuple, this code will get
broken again). As easy workaround is available (build with
-DGTEST_USE_OWN_TR1_TUPLE=1), it doesn't make sense to put this in.
Original comment by vladlosev
on 21 Feb 2012 at 4:33
- Changed state: WontFix
- Added labels: Component-Logic, OpSys-Other, Type-Enhancement, Usability
- Removed labels: Type-Defect