GTest Android build fails with STLPort and GTEST_USE_OWN_TR1_TUPLE due to invalid gtest-port.h macro test sequence.

[GoogleCodeExporter]

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]

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

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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

• Added labels: ****
• Removed labels: ****

[GoogleCodeExporter]

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

• Added labels: ****
• Removed labels: ****