Cannot compile Blender on MacOSX since September 21st

[nantille]

Yesterday it was still working. Now it isn’t.

On OSX 10.14.5 I get this error after make update and make:

/blender/extern/glog/include/glog/logging.h:640:9: error: use of overloaded operator '<<' is ambiguous (with operand types
      'std::ostream' (aka 'basic_ostream<char>') and 'const nullptr_t')
  (*os) << v;
  ~~~~~ ^  ~

It is then followed by a lot of ‘note:’ like this one:

/blender/extern/glog/include/glog/logging.h:696:3: note: in instantiation of function template specialization
      'google::MakeCheckOpValueString<nullptr_t>' requested here
  MakeCheckOpValueString(comb.ForVar2(), v2);

[ThomasDinges]

Hi,
do you still have this issue or has it been fixed by now?

Temporary build issues can always occur, but usually are fixed quickly.

[nantille]

Hi Thomas,

Now compilation fails way sooner with a clang error, around 26% (before, compilation worked until 99%). So I can’t tell if the previous error was fixed.

This sort of clang error has happened before with a commit that used cpp functions that were not supported by clang and XCode on Mojave. Not sure if this is a similar case here, which is why I prefer to report it, even if temporary build failures happen from time to time.

CMake Warning at CMakeLists.txt:1779 (message):
  -fmacro-prefix-map flag is NOT supported by C/C++ compiler.  Disabling
  WITH_COMPILER_SHORT_FILE_MACRO.


/blender/source/blender/editors/interface/interface_templates.c:529:43: warning: suggest braces around initialization of subobject [-Wmissing-braces]
  uiSearchItemTooltipData tooltip_data = {0};
                                          ^
                                          {}
1 warning generated.
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see invocation)
Apple LLVM version 10.0.1 (clang-1001.0.46.4)
Target: x86_64-apple-darwin18.6.0
Thread model: posix
InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
clang: note: diagnostic msg: PLEASE submit a bug report to http://developer.apple.com/bugreporter/ and include the crash backtrace, preprocessed source, and associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /var/folders/2l/zdf0str94330yfnmk87zl0bh0000gn/T/interface_view-bce9dc.cpp
clang: note: diagnostic msg: /var/folders/2l/zdf0str94330yfnmk87zl0bh0000gn/T/interface_view-bce9dc.sh
clang: note: diagnostic msg: Crash backtrace is located in
clang: note: diagnostic msg: /Logs/DiagnosticReports/clang_<YYYY-MM-DD-HHMMSS>_<hostname>.crash
clang: note: diagnostic msg: (choose the .crash file that corresponds to your crash)
clang: note: diagnostic msg: 

********************
make[3]: *** [source/blender/editors/interface/CMakeFiles/bf_editor_interface.dir/interface_view.cc.o] Error 254
make[3]: *** Waiting for unfinished jobs....
make[2]: *** [source/blender/editors/interface/CMakeFiles/bf_editor_interface.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
make[1]: *** [all] Error 2
make: *** [all] Error 2

[nantille]

I’ve tried compiling on Ubuntu 20 and everything works fine as opposed to MacOSX.

[ankitm]

Can redo with interface_view.cc. Can’t redo with node_geo_curve_sample.cc (Blender fails to compile macOS (clang seg fault)) though.
Checking.

EDIT
source/blender/editors/interface/interface_view.cc:48

using TreeViewPtr = std::unique_ptr<AbstractTreeView>;
...
std::variant<TreeViewPtr> view; 

is causing this.

[julianeisel]

Hi, is this still an issue?
It’s a bit weird that this fails since the minimum target macOS version we build for is 10.13, so the compiler should throw errors when using functionality introduced later. What does xcodebuild -version output for you?

Just fixing that tree-view issue is simple. Though I’d prefer not having to do it as it would mean making code worse just for some old macOS setup.

[nantille]

Hi, thanks for asking. Yes, this is still an issue.

xcodebuild -version yields:
Xcode 10.3
Build version 10G8

And no I cannot update XCode because that’s the latest I can use on Mojave.
Your fix will be appreciated.

[Tom]

Hey there,

Same problem here with Xcode 10.0. The git repo tag is “v3.0.0”.

PS: It compiled perfectly when using “xcode-select” to specify Xcode 13 - but I cannot update to 13 as the Mojave compatibility.

Any updates on this issue? Thanks!

Cheers,
Tom

[billrey]

Try removing the build directory and build from scratch - that fixed this issue for me.

[Tom]

Thanks, billrey!

Unluckily, rebuilding from scratch didn’t work for me.

Cheers,
Tom

[julianeisel]

Could those with the issue test this patch?:

diff --git a/source/blender/editors/interface/interface_view.cc b/source/blender/editors/interface/interface_view.cc
index 81b24c75020..a7cf7e6088b 100644
--- a/source/blender/editors/interface/interface_view.cc
+++ b/source/blender/editors/interface/interface_view.cc
@@ -24,6 +24,7 @@
  */
 
 #include <memory>
+#include <type_traits>
 #include <variant>
 
 #include "DNA_screen_types.h"
@@ -35,9 +36,41 @@
 #include "UI_interface.hh"
 #include "UI_tree_view.hh"
 
+/* Old XCode versions (<= 10.3?) crash when using std::variant as below.
+ * See: https://devtalk.blender.org/t/20562 */
+#ifdef __APPLE__
+#  define AVOID_STD_VARIANT
+#endif
+
 using namespace blender;
 using namespace blender::ui;
 
+#ifdef AVOID_STD_VARIANT
+struct ViewVariant {
+  using TreeViewPtr = std::unique_ptr<AbstractTreeView>;
+
+  union {
+    char none;
+    TreeViewPtr tree_view;
+    /* Other views... */
+  };
+  enum {
+    TypeNone,
+    TypeTreeView,
+  } type = TypeNone;
+
+  ViewVariant() : none()
+  {
+  }
+  ~ViewVariant()
+  {
+    if (type == TypeTreeView) {
+      tree_view = nullptr;
+    }
+  }
+};
+#endif
+
 /**
  * Wrapper to store views in a #ListBase. There's no `uiView` base class, we just store views as a
  * #std::variant.
@@ -46,14 +79,25 @@ struct ViewLink : public Link {
   using TreeViewPtr = std::unique_ptr<AbstractTreeView>;
 
   std::string idname;
+#ifdef AVOID_STD_VARIANT
+  ViewVariant view;
+#else
   /* NOTE: Can't use std::get() on this until minimum macOS deployment target is 10.14. */
   std::variant<TreeViewPtr> view;
+#endif
 };
 
 template<class T> T *get_view_from_link(ViewLink &link)
 {
+#ifdef AVOID_STD_VARIANT
+  if constexpr (std::is_same_v<T, AbstractTreeView>) {
+    return (link.view.type == ViewVariant::TypeTreeView) ? link.view.tree_view.get() : nullptr;
+  }
+  return nullptr;
+#else
   auto *t_uptr = std::get_if<std::unique_ptr<T>>(&link.view);
   return t_uptr ? t_uptr->get() : nullptr;
+#endif
 }
 
 AbstractTreeView *UI_block_add_view(uiBlock &block,
@@ -63,7 +107,12 @@ AbstractTreeView *UI_block_add_view(uiBlock &block,
   ViewLink *view_link = MEM_new<ViewLink>(__func__);
   BLI_addtail(&block.views, view_link);
 
+#ifdef AVOID_STD_VARIANT
+  view_link->view.tree_view = std::move(tree_view);
+  view_link->view.type = ViewVariant::TypeTreeView;
+#else
   view_link->view = std::move(tree_view);
+#endif
   view_link->idname = idname;
 
   return get_view_from_link<AbstractTreeView>(*view_link);