[macOS] building projects that contain C++ code segfaults

[prime31]

Zig version: 0.6.0+a1d72fad8

I don't know the exact zig version this error was introduced. It seems to be present for at least a couple weeks now. The last working version I have available is 0.6.0+a1d72fad8.

Any project that contains C++ code (C only seems to still build) fails to link. The full error is below from building this project with enableSystemLinkerHack removed (https://github.com/prime31/zig-upaya):

zig build-exe /Users/mikedesaro/Desktop/zig-upaya/examples/tilemap/main.zig --library c --library c++ --c-source -std=c99 -ObjC -fobjc-arc /Users/mikedesaro/Desktop/zig-upaya/src/deps/sokol/compile_sokol.c --c-source -std=c99 /Users/mikedesaro/Desktop/zig-upaya/src/deps/stb/src/stb_impl.c --library c++ --c-source -Wno-return-type-c-linkage /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui/cimgui/imgui/imgui.cpp --c-source -Wno-return-type-c-linkage /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui/cimgui/imgui/imgui_demo.cpp --c-source -Wno-return-type-c-linkage /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui/cimgui/imgui/imgui_draw.cpp --c-source -Wno-return-type-c-linkage /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui/cimgui/imgui/imgui_widgets.cpp --c-source -Wno-return-type-c-linkage /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui/cimgui/cimgui.cpp --c-source -Wno-return-type-c-linkage /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui/temporary_hacks.cpp --c-source -D_CRT_SECURE_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE /Users/mikedesaro/Desktop/zig-upaya/src/deps/filebrowser/src/tinyfiledialogs.c --cache-dir /Users/mikedesaro/Desktop/zig-upaya/zig-cache --name run --pkg-begin upaya /Users/mikedesaro/Desktop/zig-upaya/src/upaya.zig --pkg-begin stb /Users/mikedesaro/Desktop/zig-upaya/src/deps/stb/stb.zig --pkg-end --pkg-begin filebrowser /Users/mikedesaro/Desktop/zig-upaya/src/deps/filebrowser/filebrowser.zig --pkg-end --pkg-begin sokol /Users/mikedesaro/Desktop/zig-upaya/src/deps/sokol/sokol.zig --pkg-end --pkg-begin imgui /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui/imgui.zig --pkg-end --pkg-end --pkg-begin sokol /Users/mikedesaro/Desktop/zig-upaya/src/deps/sokol/sokol.zig --pkg-end --pkg-begin stb /Users/mikedesaro/Desktop/zig-upaya/src/deps/stb/stb.zig --pkg-end --pkg-begin imgui /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui/imgui.zig --pkg-end --pkg-begin filebrowser /Users/mikedesaro/Desktop/zig-upaya/src/deps/filebrowser/filebrowser.zig --pkg-end -I /Users/mikedesaro/Desktop/zig-upaya/src/deps/sokol -I /Users/mikedesaro/Desktop/zig-upaya/src/deps/stb/src -I /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui -I /Users/mikedesaro/Desktop/zig-upaya/src/deps/imgui/cimgui -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks -F /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/System/Library/Frameworks -framework Foundation -framework QuartzCore -framework Metal -framework MetalKit -framework OpenGL -framework Cocoa -framework Quartz -framework Audiotoolbox -framework CoreAudio --cache on 
Build Dependencies...c++ [2] Compile C Objects [29/37] strstream.cpp...Segmentation fault: 11

[andrewrk]

This isn't a regression; this is macho LLD support never being up to par with the rest of the object formats.

The good news is there is now a team maintaining the code and working on improving it; the bad news is that what is available in the upcoming LLVM 11 release is not better than status quo. Here's the diff I tried on top of the llvm11 branch:

diff --git a/cmake/Findlld.cmake b/cmake/Findlld.cmake
index 3103601ff..e20f75bad 100644
--- a/cmake/Findlld.cmake
+++ b/cmake/Findlld.cmake
@@ -42,7 +42,7 @@ else()
     FIND_AND_ADD_LLD_LIB(lldMinGW)
     FIND_AND_ADD_LLD_LIB(lldELF)
     FIND_AND_ADD_LLD_LIB(lldCOFF)
-    FIND_AND_ADD_LLD_LIB(lldMachO)
+    FIND_AND_ADD_LLD_LIB(lldMachO2)
     FIND_AND_ADD_LLD_LIB(lldWasm)
     FIND_AND_ADD_LLD_LIB(lldReaderWriter)
     FIND_AND_ADD_LLD_LIB(lldCore)
diff --git a/src/zig_llvm.cpp b/src/zig_llvm.cpp
index 5a66d0ba6..dddd0e231 100644
--- a/src/zig_llvm.cpp
+++ b/src/zig_llvm.cpp
@@ -1067,7 +1067,7 @@ bool ZigLLDLink(ZigLLVM_ObjectFormatType oformat, const char **args, size_t arg_
             return lld::elf::link(array_ref_args, false, diag_stdout, diag_stderr);

         case ZigLLVM_MachO:
-            return lld::mach_o::link(array_ref_args, false, diag_stdout, diag_stderr);
+            return lld::macho::link(array_ref_args, false, diag_stdout, diag_stderr);

         case ZigLLVM_Wasm:
             return lld::wasm::link(array_ref_args, false, diag_stdout, diag_stderr);

and here's me running the behavior tests on it:

[nix-shell:~/tmp/zig/build-llvm11-release]$ ./zig test ../test/stage1/behavior.zig -I ../test/ -target x86_64-macosx
Build Dependencies... compiler_rt [4] Build Dependencies... 
[nix-shell:~/tmp/zig/build-llvm11-release]$ echo $?
1

Silent failure... yeesh.

So what do we have to look forward to? Short term, one of two things happening:

• LLVM 12 and hopefully the LLD is improved enough to solve this bug
• @kubkon continues to stay motivated and improves the self-hosted linker enough to be able to handle this case

Long term, this will be fixed. It's just a matter of time.

[jacob-carlborg]

FYI, the official Apple ld64 linker has been ported to other platforms as part of this project [1]. Might be an interesting alternative to LLD.

[1] https://github.com/tpoechtrager/cctools-port.

[prime31]

The changes specified in #6318 work on Catalina as well. Applying them gets my C++ code compiling again.