GTest Android build fails with STLPort and GTEST_USE_OWN_TR1_TUPLE due to invalid gtest-port.h macro test sequence.
Opened this issue · 3 comments
GoogleCodeExporter commented
What steps will reproduce the problem?
Try to build GTest for Android linking against STLport with
-DGTEST_USE_OWN_TR1_TUPLE=1 set.
> The build will fail because gtest-port.h still tries to include <tr1/tuple>
The main issue has been identified by thakis@chromium.org as being due to an
invalid macro test sequence in the header. A work-around is to also use
-DGTEST_HAS_TR1_TUPLE=1 even though STLport doesn't provide <tr1/tuple>. This
allows the build to pass because the right #ifdef .. #else .. #endif blocks are
parsed.
This bug is to track the issue.
Original issue reported on code.google.com by di...@chromium.org on 3 Dec 2012 at 8:46
GoogleCodeExporter commented
The main culprit seems to be this porting of gtest-port.h:
// We use our own TR1 tuple if we aren't sure the user has an
// implementation of it already. At this time, libstdc++ 4.0.0+ and
// MSVC 2010 are the only mainstream standard libraries 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. QNX's QCC compiler is a modified GCC but it doesn't
// support TR1 tuple. libc++ only provides std::tuple, in C++11 mode,
// and it can be used with some compilers that define __GNUC__.
# if (defined(__GNUC__) && !defined(__CUDACC__) && (GTEST_GCC_VER_ >= 40000) \
&& !GTEST_OS_QNX && !defined(_LIBCPP_VERSION)) || _MSC_VER >= 1600
# define GTEST_ENV_HAS_TR1_TUPLE_ 1
# endif
The fix seems to disable this define if GTEST_HAS_TR1_TUPLE is already set to 0.
I'll provide a patch and test it.
Original comment by di...@chromium.org on 12 Dec 2012 at 2:17
GoogleCodeExporter commented
Ok, forget about the above paragraph, it seems the issue is very different than
what I originally thought.
The problem was revealed when trying to roll gtest@629 to the Chromium tree.
This actually broke the Android build (which uses STLport).
The reason for this is that the build file sets -DGTEST_USE_OWN_TR1_TUPLE=1
when building gtest or any of its dependents, but doesn't set
GTEST_HAS_TR1_TUPLE.
With gtest@629, GTEST_USE_OWN_TR1_TUPLE is ignored if GTEST_HAS_TR1_TUPLE is 0,
which happens to be the case on Android when building against STLport.
GTest builds fine, but any GTest client that tries to use std::tuple<> will
then fail to build, because gtest-port.h didn't include any of <tuple>,
<tr1/tuple> or "gtest/internal/gtest-tuple.h". This happens with GMock.
One work-around is to also set GTEST_HAS_TR1_TUPLE to 1 in the build file.
The documentation in gtest-port.h mentions that the GTest gtest-tuple.h header
should be used is GTEST_USE_OWN_TUPLE is set to 1, i.e. it doesn't mention that
this is conditional to the definition of GTEST_HAS_TR1_TUPLE.
The same documentation also mention that GTEST_HAS_TR1_TUPLE should be set to 1
to indicate that <tr1/tuple> is available (clearly this isn't the case here).
As such, it's probably better to fix the header to make it work properly,
according to the documentation, i.e.
if (GTEST_USE_OWN_TUPLE==1) then
always include "gtest-tuple.h"
else
include <tuple> or <tr1/tuple> depending on GTEST_HAS_TR1_TUPLE and
other (compiler) macros.
fi
Original comment by di...@chromium.org on 12 Dec 2012 at 4:44
GoogleCodeExporter commented
Just FYI. Here are two patches that I think is related to this issue.
From macports:
https://trac.macports.org/attachment/ticket/40910/tuple.patch
From pkgsrc:
http://cvsweb.netbsd.org/bsdweb.cgi/pkgsrc/devel/googletest/patches/patch-includ
e_gtest_internal_gtest-port.h
Original comment by kirk.j.r...@gmail.com on 7 Mar 2015 at 10:27