rust fails to bootstrap when llvm 3.3 is installed in system

[ehsanul]

I'm having trouble building rust on master lately. Here's the entire error:

compile_and_link: x86_64-apple-darwin/stage0/lib/rustc/x86_64-apple-darwin/lib/libsyntax.dylib
cp: x86_64-apple-darwin/stage1/lib/libextra.dylib
compile_and_link: x86_64-apple-darwin/stage0/lib/rustc/x86_64-apple-darwin/lib/librustc.dylib
cp: x86_64-apple-darwin/stage1/lib/libsyntax.dylib
error: ar s x86_64-apple-darwin/stage0/lib/rustc/x86_64-apple-darwin/lib/librustc-5b94a16f-0.9-pre.rlib failed with: exit code: 1
note: stdout ---

note: stderr ---
Assertion failed: (isValidElementType(ElementType) && "Elements of a VectorType must be a primitive type"), function get, file Type.cpp, line 708.
ar: fatal error in /opt/local/bin/ranlib

error: aborting due to previous error
task 'rustc' failed at 'explicit failure', /Users/rustbuild/src/rust-buildbot/slave/snap3-mac/build/src/libsyntax/diagnostic.rs:102
task '<main>' failed at 'explicit failure', /Users/rustbuild/src/rust-buildbot/slave/snap3-mac/build/src/librustc/lib.rs:442

I tracked it down to this pull request: #10918

Commenting out the #[inline] attribute makes rust compile successfully for me.

I am on OSX 10.8.4, x86_64

[ehsanul]

@alexcrichton: @cmr told me on IRC that I should ping you on this.

[alexcrichton]

I find it very odd that commenting out an #[inline] attribute would fix this. I've seen this problem before, but it's totally unrelated to finalizers in finally.

I have seen this in the past trip up because we're adding files to archives that aren't object files, but I've also heard that this was all previously fixed... I wish I could research more into this, but I can't reproduce this at all on any machine I have.

[ehsanul]

Yes, it does seem pretty inexplicable, but I thought you might have a clue.

I am content with the commenting out the #[inline] attribute for the time being, so I can at least track master. But I could try to debug this myself if I knew where to start..

[alexcrichton]

Editing title to reflect the real problem here as found out by #11260

[alexcrichton]

Also, #11260 hints that uninstalling the system LLVM is a workaround for this.

[ehsanul]

Seems to be non-trivial to remove LLVM on OSX, after having installed it. I tried moving all llvm-related libs I could fine out of my PATH, but that didn't seem to make a difference.

[alexcrichton]

We may be able to just not run ar s ... on OSX because it appeared to bootstrap just fine. I think maybe the linkers on linux may need this, but perhaps the ones on OSX are more controlled such that we may not need it.

I haven't investigated it much, but it's one possible solution for this.

[knardi]

I'm having this issue as well. I'm not sure I want to try to uninstall my system LLVM, given that it's very likely to break Xcode.

[knardi]

Any idea how I can try disabling the "ar s" execution? I can't seem to find it. It's very hard to grep for. :P

[dymk]

+1, I'm also having this problem (and can't build on OSX 10.9 because of it)

[knardi]

Just wanted to point out that this is still failing with the same error on my machine, which I assume is because the stage0 snapshot is from 3 days before this commit went in. I'll check back when this makes it into the stage0 snapshot.

[dymk]

Yep, still fails to compile on OSX 10.9 with LLVM 3.3 installed. How often are snapshots updated?

[alexcrichton]

A new snapshot is scheduled in #11699 (currently third in the queue).

[m4rw3r]

This error was resolved for me with the new snapshot rust-stage0-2014-01-20-b6400f9-macos-x86_64-6458d3b46a951da62c20dd5b587d44333402e30b.tar.bz2.

[knardi]

This is resolved for me as well.