Have rust build its llvm itself #85
Conversation
Since poky rev: f8520142c8a33fa9414314511fb01fbe79a2bf01, oe-core rev: aeb653861a0ec39ea7a014c0622980edcbf653fa
When rust's build system builds llvm itself, it uses these flags. Avoid them interfering with other things by cleaning their usage out of the platform cfg mk file.
rustllvm ships some c++ code that we need to ensure is built with the flags we want. Abuse an existing variable to make this happen. This should fix our issues with the libstdc++ cxx11 abi (_GLIBCXX_USE_CXX11_ABI).
codyps
changed the title
|
@jmesmon I'll give this a whirl on Monday or Tuesday. |
|
Well I've been able to build this and verify it builds something that works so 👍. But WOW it takes long to build |
|
Strange that this makes the build take longer. I would think that we're building the same amount of code either way. Perhaps this builds LLVM with a lower -j level or something? The reason I pulled rust-llvm into its own recipe was to reduce the amount of code that had to be built between rust-native and various rust-cross flavors; rust-llvm-native was common to all of them. However, now that the only real compiler is rust-native, that reasoning no longer applies. So, given that, I don't have a problem with these changes. It would be nice to better understand the build time penalty, though :-) |
|
Its similar on Gentoo. Its quicker to build the Gentoo LLVM package and build the Rust package against the system LLVM than building Rust with its shipped LLVM. |
|
It's possible parallelization isn't being done properly for the llvm sub-build. I'll take a quick look. I suppose we could consider keeping the rust-llvm separate to add another "cancellation point" of sorts: if part of the rust build fails, we'll still have the rust-llvm build done (potentially), and won't need to rebuild quite so much. In updating to 1.12.0 ( #89 ), I've noticed that the support that rust has for building llvm isn't that great (not passing flags through), so it might be less work in the long run to take more control of that build process and do it ourselves. Any thoughts on supporting using a generic llvm for rustc and how that might affect using a separate package for rust-llvm? (though meta-oe doesn't seem like it's packaging a new enough version at the moment) Edit: I'm going to pull out the other fixes in this and open a separate PR for them while we figure out the rust-llvm question. |
|
So one argument against this would be that LLVM doesn't often change for Rust so we could probably keep the same build of LLVM and get newer versions of Rust built against it. |
|
I'm planning on taking a look at the llvm support that is in meta-oe already & see if we can use "normal llvm" plus the few backport patches that rust needs instead of building our own. Should also help out other folks who want to use llvm within oe. |
|
FYI, the release notes for rust 1.12 say it should build against LLVM 3.9 |
|
Closing this for now as it seems like going the mainline-llvm route would be more beneficial. If we do ever want to have rustc build llvm though, it's a simple matter of removing the depend and a single configure flag. On the release notes: It may build with plain 3.9, the problem is what happens afterwards :) . There are some codegen bugs that rust's shipped llvm has backports to fix: rust-lang/rust#36023 (and a few optimization patches). So we'll probably need to include a few patches to apply to the release llvm version. |
…-by-default chromium-ozone-wayland: Disable Jumbo builds by default.
Fixes #80 .
This also appears to handle #47 for me (at least with a gcc 5.2 host).