[C++] Issues with GTest when building Arrow C++ on MacOS

[AlenkaF]

Describe the bug, including details regarding any error messages, version, and platform.

I have seen errors with GTest when building Arrow C++ on MacOS come up regularly, probably due to lack of some symbols or incompatibility of the supplied library . An error log is similar to:

FAILED: debug/arrow-array-test 
: && /usr/bin/c++ -fno-aligned-new  -Qunused-arguments -fcolor-diagnostics -ggdb -O0  -Wall -Wextra -Wdocumentation -Wshorten-64-to-32 -Wno-missing-braces -Wno-unused-parameter -Wno-constant-logical-operand -Wno-return-stack-address -Werror -Wno-unknown-warning-option -Wno-pass-failed -march=armv8-a  -g -arch arm64 -isysroot /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX13.0.sdk -Wl,-search_paths_first -Wl,-headerpad_max_install_names  src/arrow/CMakeFiles/arrow-array-test.dir/array/array_test.cc.o src/arrow/CMakeFiles/arrow-array-test.dir/array/array_binary_test.cc.o src/arrow/CMakeFiles/arrow-array-test.dir/array/array_dict_test.cc.o src/arrow/CMakeFiles/arrow-array-test.dir/array/array_list_test.cc.o src/arrow/CMakeFiles/arrow-array-test.dir/array/array_struct_test.cc.o src/arrow/CMakeFiles/arrow-array-test.dir/array/array_union_test.cc.o src/arrow/CMakeFiles/arrow-array-test.dir/array/array_view_test.cc.o -o debug/arrow-array-test  -Wl,-rpath,/Users/sanjibansengupta/voltrondata/fix-partitioning/arrow/cpp/build/debug/ -Wl,-rpath,/Users/sanjibansengupta/opt/anaconda3/lib -Wl,-rpath,/opt/homebrew/lib  debug/libarrow_testing.1000.0.0.dylib  debug/libarrow.1000.0.0.dylib  /opt/homebrew/lib/libutf8proc.dylib  /opt/homebrew/lib/libre2.9.0.0.dylib  /opt/local/lib/libgtest_main.a  /opt/local/lib/libgtest.a  /opt/local/lib/libgmock.a  mimalloc_ep/src/mimalloc_ep/lib/mimalloc-2.0/libmimalloc-debug.a  /opt/local/lib/libgtest.a && :
Undefined symbols for architecture arm64:
  "testing::Matcher<std::__1::basic_string_view<char, std::__1::char_traits<char> > const&>::Matcher(char const*)", referenced from:
      testing::Matcher<std::__1::basic_string_view<char, std::__1::char_traits<char> > const&> testing::internal::MatcherCastImpl<std::__1::basic_string_view<char, std::__1::char_traits<char> > const&, char const*>::CastImpl<true>(char const* const&, std::__1::integral_constant<bool, true>, std::__1::integral_constant<bool, true>) in array_test.cc.o
      testing::Matcher<std::__1::basic_string_view<char, std::__1::char_traits<char> > const&> testing::internal::MatcherCastImpl<std::__1::basic_string_view<char, std::__1::char_traits<char> > const&, char const*>::CastImpl<true>(char const* const&, std::__1::integral_constant<bool, true>, std::__1::integral_constant<bool, true>) in array_binary_test.cc.o
ld: symbol(s) not found for architecture arm64
clang: error: linker command failed with exit code 1 (use -v to see invocation)

In these cases the CMake flag -DGTest_SOURCE="BUNDLED solves the issue.

As this error came up a lot recently, I think we should add this info to the official documentation.

Component(s)

Documentation

[mhconradt]

@AlenkaF does this happen after using the Conda instructions in the Python development docs?

[AlenkaF]

@mhconradt as far as I can see there have been different ways users tried to build Arrow C++ and were facing this issue (Conda and pip/Homebrew via C++ instructions or Python instructions)

[westonpace]

@AlenkaF does this happen after using the Conda instructions in the Python development docs?

@mhconradt

Yes. It appears that conda's recipe has the same issue. I have verified this manually using the reproducer in Homebrew/homebrew-core#111810

I think conda just uses the cmake file as is and clang defaults to C++14 if not specified.

[HaochengLIU]

Hi, I was bitten by this issue as well when building Arrow cpp on Mac M2 chips. The linked PR #34234 though does not update the doc nor add the -DGTest_SOURCE="BUNDLED" in CMakeLists.txt. Wondering if it's been actively worked on by some one?

[AlenkaF]

The linked PR #34234 though does not update the doc nor add the -DGTest_SOURCE="BUNDLED" in CMakeLists.txt.

The PR is not linked to this issue, there is only a mention of the workaround for the build failures that the PR author also had.

Wondering if it's been actively worked on by some one?

Nobody is assigned so I think there is no active work being done. But contributions are very welcome!

[HaochengLIU]

Hi Alenka, thanks for the explanation and I will try to come up with a fix in my spare cycle.