Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

LLVM will not build on latest macOS+xcode #36650

Closed
sophiajt opened this issue Sep 22, 2016 · 12 comments
Closed

LLVM will not build on latest macOS+xcode #36650

sophiajt opened this issue Sep 22, 2016 · 12 comments

Comments

@sophiajt
Copy link
Contributor

On macOS Sierra (10.12) and Xcode 8.0 (8A218a)

When building the latest Rust, I fail during our LLVM build at:

[ 61%] Building CXX object lib/Analysis/CMakeFiles/LLVMAnalysis.dir/ValueTracking.cpp.o
[ 61%] Building CXX object lib/Analysis/CMakeFiles/LLVMAnalysis.dir/VectorUtils.cpp.o
[ 61%] Linking CXX static library ../libLLVMAnalysis.a
[ 61%] Built target LLVMAnalysis
make: *** [all] Error 2
thread 'main' panicked at '
command did not execute successfully, got: exit code: 2
@sophiajt
Copy link
Contributor Author

More information: After a fresh checkout, I'm seeing it crash here (using rustbuild):

# command-line-arguments
fatal error: unexpected signal during runtime execution
[signal 0xb code=0x1 addr=0xcf39d307ea2 pc=0xf47b]

runtime stack:
runtime.throw(0x2c4900, 0x2a)
    /usr/local/go/src/runtime/panic.go:547 +0x90
runtime.sigpanic()
    /usr/local/go/src/runtime/sigpanic_unix.go:12 +0x5a
runtime.unlock(0x3a60a0)
    /usr/local/go/src/runtime/lock_sema.go:107 +0x14b
runtime.(*mheap).alloc_m(0x3a60a0, 0x1, 0x40000000009, 0x513440)
    /usr/local/go/src/runtime/mheap.go:492 +0x314
runtime.(*mheap).alloc.func1()
    /usr/local/go/src/runtime/mheap.go:502 +0x41
runtime.systemstack(0xc82003be58)
    /usr/local/go/src/runtime/asm_amd64.s:307 +0xab
runtime.(*mheap).alloc(0x3a60a0, 0x1, 0x10000000009, 0xf11f)
    /usr/local/go/src/runtime/mheap.go:503 +0x63
runtime.(*mcentral).grow(0x3a7760, 0x0)
    /usr/local/go/src/runtime/mcentral.go:209 +0x93
runtime.(*mcentral).cacheSpan(0x3a7760, 0x49cdb0)
    /usr/local/go/src/runtime/mcentral.go:89 +0x47d
runtime.(*mcache).refill(0x401e10, 0xc800000009, 0x49cdb0)
    /usr/local/go/src/runtime/mcache.go:119 +0xcc
runtime.mallocgc.func2()
    /usr/local/go/src/runtime/malloc.go:642 +0x2b
runtime.systemstack(0xc82001c000)
    /usr/local/go/src/runtime/asm_amd64.s:291 +0x79
runtime.mstart()
    /usr/local/go/src/runtime/proc.go:1051

goroutine 1 [running]:
runtime.systemstack_switch()
    /usr/local/go/src/runtime/asm_amd64.s:245 fp=0xc8200386f8 sp=0xc8200386f0
runtime.mallocgc(0x80, 0x0, 0x3, 0x0)
    /usr/local/go/src/runtime/malloc.go:643 +0x869 fp=0xc8200387d0 sp=0xc8200386f8
runtime.rawstring(0x75, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/runtime/string.go:284 +0x70 fp=0xc820038818 sp=0xc8200387d0
runtime.rawstringtmp(0x0, 0x75, 0x0, 0x0, 0x0, 0x0, 0x0)
    /usr/local/go/src/runtime/string.go:111 +0xb7 fp=0xc820038850 sp=0xc820038818
runtime.slicebytetostring(0x0, 0xc820959f80, 0x75, 0x75, 0x0, 0x0)
    /usr/local/go/src/runtime/string.go:93 +0x6f fp=0xc8200388e8 sp=0xc820038850
strings.Replace(0xc820afccb0, 0x61, 0x27cba0, 0x3, 0xc820038a00, 0x8, 0x4, 0x0, 0x0)
    /usr/local/go/src/strings/strings.go:675 +0x53d fp=0xc8200389b8 sp=0xc8200388e8
cmd/link/internal/ld.expandpkg(0xc820afccb0, 0x61, 0x27e550, 0x7, 0x0, 0x0)
    /usr/local/go/src/cmd/link/internal/ld/go.go:21 +0xb4 fp=0xc820038a28 sp=0xc8200389b8
cmd/link/internal/ld.rdsym(0xc820072240, 0xc820128ec0, 0x27e550, 0x7, 0x0)
    /usr/local/go/src/cmd/link/internal/ld/objfile.go:459 +0x1f3 fp=0xc820038b38 sp=0xc820038a28
cmd/link/internal/ld.readsym(0xc820072240, 0xc820128ec0, 0x27e550, 0x7, 0xc820122f00, 0x30)
    /usr/local/go/src/cmd/link/internal/ld/objfile.go:249 +0xd5b fp=0xc820038f80 sp=0xc820038b38
cmd/link/internal/ld.ldobjfile(0xc820072240, 0xc820128ec0, 0x27e550, 0x7, 0x2a19eb, 0xc820122f00, 0x30)
    /usr/local/go/src/cmd/link/internal/ld/objfile.go:147 +0xa62 fp=0xc820039190 sp=0xc820038f80
cmd/link/internal/ld.ldobj(0xc820128ec0, 0x27e550, 0x7, 0x2a1a45, 0xc820122f00, 0x30, 0xc820012510, 0x28, 0x1, 0x0)
    /usr/local/go/src/cmd/link/internal/ld/lib.go:1351 +0x1569 fp=0xc820039400 sp=0xc820039190
cmd/link/internal/ld.objfile(0xc82001a460)
    /usr/local/go/src/cmd/link/internal/ld/lib.go:847 +0x10d9 fp=0xc820039710 sp=0xc820039400
cmd/link/internal/ld.loadlib()
    /usr/local/go/src/cmd/link/internal/ld/lib.go:513 +0x5ce fp=0xc8200399f0 sp=0xc820039710
cmd/link/internal/ld.Ldmain()
    /usr/local/go/src/cmd/link/internal/ld/pobj.go:214 +0x1cd3 fp=0xc820039e70 sp=0xc8200399f0
cmd/link/internal/amd64.Main()
    /usr/local/go/src/cmd/link/internal/amd64/obj.go:44 +0x19 fp=0xc820039e78 sp=0xc820039e70
main.main()
    /usr/local/go/src/cmd/link/main.go:27 +0x36f fp=0xc820039f50 sp=0xc820039e78
runtime.main()
    /usr/local/go/src/runtime/proc.go:188 +0x2b0 fp=0xc820039fa0 sp=0xc820039f50
runtime.goexit()
    /usr/local/go/src/runtime/asm_amd64.s:1998 +0x1 fp=0xc820039fa8 sp=0xc820039fa0
make[2]: *** [bin/llvm-go] Error 2
make[1]: *** [tools/llvm-go/CMakeFiles/llvm-go.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

@sophiajt
Copy link
Contributor Author

cc @brson and @alexcrichton

@sophiajt
Copy link
Contributor Author

I'm seeing it crash at different places building LLVM. The second comment is from a different crash site:

[ 24%] Linking CXX static library ../../libLLVMDebugInfoPDB.a
[ 24%] Built target LLVMDebugInfoPDB
make: *** [all] Error 2
thread 'main' panicked at '

@brson
Copy link
Contributor

brson commented Sep 22, 2016

It seems to be an error building llvm-go, which we should not be building.

@brson
Copy link
Contributor

brson commented Sep 22, 2016

I think the setting that controls this in cmake is LLVM_BINDINGS. If we set that to "" in src/bootstrap/native.rs that may disable the feature.

@sophiajt
Copy link
Contributor Author

Found the corresponding error for the first crash listed:

[ 58%] Building CXX object lib/CodeGen/CMakeFiles/LLVMCodeGen.dir/TargetRegisterInfo.cpp.o
In file included from /Users/jturner/Source/rust/src/llvm/lib/ExecutionEngine/Orc/OrcRemoteTargetRPCAPI.cpp:10:
In file included from /Users/jturner/Source/rust/src/llvm/include/llvm/ExecutionEngine/Orc/OrcRemoteTargetRPCAPI.h:21:
In file included from /Users/jturner/Source/rust/src/llvm/include/llvm/ExecutionEngine/Orc/RPCUtils.h:35:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1447:23: error: 'future_error' is unavailable: introduced in macOS 10.8
                      future_error(make_error_code(future_errc::broken_promise))
                      ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:502:63: note: 'future_error' has been explicitly marked unavailable here
class _LIBCPP_EXCEPTION_ABI _LIBCPP_AVAILABILITY_FUTURE_ERROR future_error
                                                              ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:1621:23: error: 'future_error' is unavailable: introduced in macOS 10.8
                      future_error(make_error_code(future_errc::broken_promise))
                      ^
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../include/c++/v1/future:502:63: note: 'future_error' has been explicitly marked unavailable here
class _LIBCPP_EXCEPTION_ABI _LIBCPP_AVAILABILITY_FUTURE_ERROR future_error
                                                              ^
2 errors generated.
make[2]: *** [lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/OrcRemoteTargetRPCAPI.cpp.o] Error 1
make[1]: *** [lib/ExecutionEngine/Orc/CMakeFiles/LLVMOrcJIT.dir/all] Error 2
make[1]: *** Waiting for unfinished jobs....

@brson
Copy link
Contributor

brson commented Sep 22, 2016

Maybe LLVM's CMake is not detecting libc++ or libc++abi correctly. I've seen similar but different errors before on old versions of OS X. Don't recall the fix.

On OS X you might expect to see:

x86_64-unknown-linux-gnu/llvm/build/CMakeCache.txt
560:LLVM_ENABLE_LIBCXX:BOOL=ON
563:LLVM_ENABLE_LIBCXXABI:BOOL=ON

@sophiajt
Copy link
Contributor Author

I see:

//Use libc++ if available.
LLVM_ENABLE_LIBCXX:BOOL=OFF

//Use libc++abi when using libc++.
LLVM_ENABLE_LIBCXXABI:BOOL=OFF

@sophiajt
Copy link
Contributor Author

Manually disabling the Go bindings got me back to dying on the first error mentioned. Googling around, other people are hitting this: https://forums.developer.apple.com/thread/63266

@sophiajt sophiajt mentioned this issue Sep 22, 2016
Closed
@alexcrichton
Copy link
Member

@jonathandturner let's go ahead and just remove this MACOSX_DEPLOYMENT_TARGET env var entirely. We're not using rustbuild for release artifacts, it fixes a regression, and the builders already set this env var.

@alexcrichton
Copy link
Member

Er, that was intended for the PR, but the gist is the same where we can just deal with this in rustbuild when necessary.

@sophiajt sophiajt mentioned this issue Sep 27, 2016
Merged
@sophiajt
Copy link
Contributor Author

@alexcrichton new PR at #36784

sophiajt pushed a commit to sophiajt/rust that referenced this issue Sep 28, 2016
Rollup merge of rust-lang#36784 - jonathandturner:env_var, r=alexcric…
723ddd1 
…hton

Remove requirement to use 10.7 (fixes macOS)

Fixes rust-lang#36650 by removing the requirement to use 10.7.  @alexcrichton pointed out that the buildbots won't be affected, since they set the requirement with an environment variable.

This should now allow rustbuild to build Rust on macOS (nee OS X)

r? @alexcrichton
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
3 participants
@alexcrichton @brson @sophiajt