Bug 223342
| Summary: | lang/rust: unbreak cfg_target_feature for PORT_LLVM=on | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Jan Beich <jbeich> | ||||
| Component: | Individual Port(s) | Assignee: | FreeBSD Rust Team <rust> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Only Me | CC: | 2khramtsov, brooks, dumbbell, freebsd-2024, jcfyecrayz, pi, riggs, rust, sid | ||||
| Priority: | --- | Keywords: | patch, regression | ||||
| Version: | Latest | Flags: | dumbbell:
maintainer-feedback+
|
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| See Also: |
https://github.com/rust-lang/rust/issues/46181 https://github.com/rust-lang/rust/pull/49428 |
||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 223300, 223314 | ||||||
| Attachments: |
|
||||||
|
Description
Jan Beich
2017-10-31 15:03:57 UTC
Comment on attachment 187613 [details] v0 devel/llvm50 patch here is due to Rust being close to upgrading bundled LLVM. https://github.com/rust-lang/rust/issues/43370 devel/llvm-devel because it's not clear whether Rust plans to upstream the patch after cfg_target_feature is stabilized. I would be in favor of dropping the LLVM_PORT option from lang/rust. We don't know how well tested this combination is. This time we hit a regression visible at compile time, but it could be worse. Unfortunately, I don't know how popular this option is. Opinions? I've been using the LLVM_PORT option for a while with no problems until now. Saves a healthy chunk of time and space.
I tested with attachment 187613 [details] - firefox compiles now, and I've had no problems yet. The patch is pretty simple (just adds some accessors) and seems like it could be acceptable upstream. I wonder if the rust-lang folks have already submitted the change.
I have not analyzed what else is different between rust-llvm and normal llvm. That would be good information.
I think the port llvm option should be dropped, while not overriding llvm version from ports in make.conf. It should make troubleshooting easier, and those who use or test llvm from ports would still be able to do so from make.conf. (In reply to sid from comment #4) I am also in favor of dropping the LLVM_PORT option. Building rust is compilated enough as it is, we gain very little from supporting build configuration which are not supported upstream. I'm preparing a patch to update lang/rust to 1.22.1. Once this is committed, I'm going to remove the PORT_LLVM option. The user support headache can be greater than the benefit of this option. A commit references this bug: Author: dumbbell Date: Mon Nov 27 18:16:15 UTC 2017 New revision: 454983 URL: https://svnweb.freebsd.org/changeset/ports/454983 Log: lang/rust: Remove the LLVM_PORT option FTR, this option allowed to used LLVM from ports instead of building the bundled copy. The problem is that this combination isn't really tested upstream. This led to regressions which are difficult to diagnose. For instance, in Rust 1.21.0, the bundled LLVM provided a new API to query the features supported by the target arch. The equivalent code inside Rust was removed to use that new API. Unfortunately, building Rust 1.21.0+ with a copy of LLVM not providing this API didn't failed but instead made that list of CPU features empty. This resulted in the following obscure build failure in Firefox: error[E0432]: unresolved import `x86::sse2` To avoid future pain for both end users and maintainers, we decided to remove that option. Yes, it will increase the (already long) time to build Rust, but it should save time wasted on debugging what is not really supported anyway. PR: 223342, 223300 Reported by: Many users Changes: head/lang/rust/Makefile head/lang/rust/files/config.toml > this option allowed to used LLVM from ports instead of building the > bundled copy. This should never even have been an option -- it should always have been the only way (unless the LLVM-pieces from the base are sufficient). I'm not going to repeat the arguments included here: https://www.freebsd.org/doc/en/books/porters-handbook/bundled-libs.html they all apply -- using bits and pieces of other projects bundled with the software being ported is Just Wrong[TM]. The arguments like "we don't know" or "how well-tested is it" are nothing but FUD -- rust is not tested (by its developers) on FreeBSD as well, should we all switch to Linux? Yes, the option adds difficulty reproducing reported problems -- so get rid of the option, but make the behavior _standard_. A port is supposed to provide the BEST way of building a piece of software on FreeBSD. Not just "a way", but the best way... > the bundled LLVM provided a new API to query the features supported Then the new API should be added to the LLVM port(s), as jbeich@ was suggesting from the beginning. The bad old days of building a special ("well tested") version of the C-compiler for the sake of one application (think lang/gcc-ooo) may be back... The edit is good. It will help diagnose problems. The port should not override the compiler chosen from /etc/make.conf, if that's what someone meant when they said make it standard, because that restricts testing for that, and it will make ports inconvenient in the future. Should be fixed in Rust 1.26.0 but I haven't tried. https://reviews.freebsd.org/D32654 to restore PORT_LLVM for 1.56. |