Compiling latest branch on MacOS fails (again, with a new error)

Blender Development Building Blender
#1

I ran make update yesterday and I’ve got this error (MacOS Mojave):

It seems to be related to [source/blender/editors/space_spreadsheet/CMakeFiles/bf_editor_space_spreadsheet.dir/spreadsheet_column_layout.cc.o] and [source/blender/editors/space_spreadsheet/CMakeFiles/bf_editor_space_spreadsheet.dir/spreadsheet_from_geometry.cc.o]

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.
[ 34%] Building CXX object source/blender/blenlib/CMakeFiles/bf_blenlib.dir/intern/mesh_boolean.cc.o
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/spreadsheet_column_layout-f2adf7.cpp
clang: note: diagnostic msg: /var/folders/2l/zdf0str94330yfnmk87zl0bh0000gn/T/spreadsheet_column_layout-f2adf7.sh
clang: note: diagnostic msg: Crash backtrace is located in
clang: note: diagnostic msg: /Users/.../Library/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/space_spreadsheet/CMakeFiles/bf_editor_space_spreadsheet.dir/spreadsheet_column_layout.cc.o] Error 254
make[3]: *** Waiting for unfinished jobs....
[ 34%] Building C object source/blender/bmesh/CMakeFiles/bf_bmesh.dir/intern/bmesh_mesh.c.o
Scanning dependencies of target bf_ikplugin
[ 34%] Building C object source/blender/ikplugin/CMakeFiles/bf_ikplugin.dir/intern/ikplugin_api.c.o
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.
[ 34%] Building C object source/blender/ikplugin/CMakeFiles/bf_ikplugin.dir/intern/iksolver_plugin.c.o
[ 34%] Building C object source/blender/render/CMakeFiles/bf_render.dir/intern/render_result.c.o
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/spreadsheet_from_geometry-c3739a.cpp
clang: note: diagnostic msg: /var/folders/2l/zdf0str94330yfnmk87zl0bh0000gn/T/spreadsheet_from_geometry-c3739a.sh
clang: note: diagnostic msg: Crash backtrace is located in
clang: note: diagnostic msg: /Users/.../Library/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/space_spreadsheet/CMakeFiles/bf_editor_space_spreadsheet.dir/spreadsheet_from_geometry.cc.o] Error 254
make[2]: *** [source/blender/editors/space_spreadsheet/CMakeFiles/bf_editor_space_spreadsheet.dir/all] Error 2
make[2]: *** Waiting for unfinished jobs....
#2

I’m seeing this, too.

-- Detected OS X 10.14 and Xcode 10.3 at /Applications/Xcode.app/Contents/Developer
-- SDKs Directory: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs
-- Detected OSX_SYSROOT: /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.14.sdk
-- Using /Users/georgevdd/src/blender-git/blender/../lib/darwin/openmp for OpenMP
-- SSE2 SIMD instructions enabled
-- Unsupported CFLAG: -Wno-misleading-indentation
-- Unsupported CXXFLAG: -Wno-misleading-indentation
-- Unsupported CFLAG: -fmacro-prefix-map=foo=bar
-- Unsupported CXXFLAG: -fmacro-prefix-map=foo=bar
CMake Warning at CMakeLists.txt:1767 (message):
  -fmacro-prefix-map flag is NOT supported by C/C++ compiler.  Disabling
  WITH_COMPILER_SHORT_FILE_MACRO.
...
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.7.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.
#3

Reverting https://github.com/blender/blender/commit/5ad4713cd8ed2943d96a020ba63ed4d611d14007 gets us back to linker errors instead of compiler errors.

Instead commenting out various sets of lines and recompiling suggests this is a Clang bug that’s tickled by the use of std::variant in CellValue.

In investigating it, I found a fairly recent report that std::variant is actually quite broken in Clang, so I wonder whether the right thing is to avoid it entirely.

#4

Thanks @georgevdd for spotting the issue. @jacqueslucke If this is the only place in Blender codebase where std::variant is used, could you please change your code so that we can get compilation working?

#5

Xcode 11.3.x, with a newer version of clang, should still be supported on Mojave. Is it possible for you folks to upgrade and see if the clang bug has been fixed?

#6

Not sure why it does not work for you, but does work on the buildbot. However, there still seem to be some issues surrounding std::variant indeed. So yeah, I better replace it with something else. I wonder if compiler support is better for std::any.

#7

@nantille can you try if master plus https://developer.blender.org/P2045 compiles?

#8

Not sure why it does not work for you, but does work on the buildbot.

It builds on LLVM clang 13 too. So guess it got fixed sometime in between ?

std::any blah = std::make_any<int>(43);
auto t = std::any_cast<int>(blah);

Call to unavailable function 'any_cast': introduced in macOS 10.14
We’re targeting macOS 10.13.

#9

Hm, thanks for testing, so can’t use std::any either…
@ankitm does std::variant, the way I used it, work in the minimum version we support or do I need to replace it?

#10

macOS 10.13 users can use Xcode 10.1 (thus Apple Clang 10.x) as the latest version so the crash reported here needs to be side stepped. There are no “introduced in macOS blah” warnings though.

There’s a long winded way to use LLVM toolchain in Xcode to use recent Clang versions with old Xcode versions, but we shouldn’t expect everyone to do it.

#11

This happens due to OpenMP. I experienced a crash last year while compiling an OBJ-C file with -fopenmp.
It was a missing null check and was fixed and released in LLVM 12.
I don’t know if this is the same as the OBJ-C + OpenMP bug.

Workaround is cmake -DWITH_OPENMP=OFF . in build folder.

For the record: OpenMP + Clang 10 + std::variant is not good.

#12

I removed the use of std::variant now. Hope it works again.

#13

@deadpin, your suggestion to update XCode was the opposite of what I asked. It’s not necessarily a bag thing but it looked awfully like the behaviour of large industries in our society: if a consumer asks for a modification because of a problem, the producer offloads the responsibility onto the consumer and ignores the request. Example: all the big brands out there who produce hundreds of millions of plastic bottles and packaging, saying that since people buy them, they’re responsible for it. With respect to software development, engineers (I’m one of them) have a responsibility in making their software available to common hardware, because it’s not a sustainable approach to make people buy new hardware for every supposedly cutting edge feature.

And you might wonder why the ramble? Because I’ve got a macbook pro mid-2012 and I cannot update to any new MacOS as Catalina dropped support for it. So I can only install XCode 11.3.1. And if later another similar issue happens, this would mean “buy a new computer”. And if a developer can, with little efforts make that computer live longer for my use, I’ll push for it. Of course, I don’t like Apple’s way of doing business so I’ve got a second-hand workstation with Ubuntu and Windows as alternative for the day when I won’t be able to compile Blender anymore. :slight_smile:

Anyway @deadpin , I know you probably only wanted to help and you actually did so thank you for that. I hope you will understand why I mentioned this. And it’s clearly more Apple the culprit here when it comes to make things obsolete sooner than they should (but we all know they will do nothing to change that).

Meanwhile, I updated XCode to 11.3.1 and compilation works but linking still fails as I reported in a previous post and as @georgevdd said. There is no solution yet except downloading and using (at your own risk) the precompiled python 3.9 lib provided by @ankitm here: https://developer.blender.org/F9865901

Btw, if you update or downgrade XCode, there is a systematic import error with al.h for OpenAL at compilation time. This is solved by removing build_darwin/CMakeCache.txt before make.

Thanks @jacqueslucke for looking at this. If your target is MacOS 10.13, such users won’t be able to update to XCode 11 to solve the issue, so I guess it’s good that you found an alternative for std::variant and std::any. :slight_smile:

I tested with both XCode 10.03 and 11.3.1, compilation succeeds, except linking as mentioned above.