On 2019-12-25 00:33 +0000, Ken Moffat via blfs-dev wrote: > On Tue, Dec 24, 2019 at 04:59:53PM -0600, Douglas R. Reno via blfs-dev wrote: > > On 12/24/19 3:14 PM, Ken Moffat via blfs-dev wrote: > > > On Mon, Dec 23, 2019 at 10:09:17PM +0000, Ken Moffat via blfs-dev wrote: > > > > Arch have a patch for thunderbird, described as for rustc-1.39.0. > > > > https://git.archlinux.org/svntogit/packages.git/plain/trunk/thunderbird-rust-1.39.patch?h=packages/thunderbird > > > > > > > There is also thunderbird beta in arch (currently 72.0b2 - > > > thunderbird tracks firefox major releases, but non-ESR are only > > > ever beta, although a comment suggests that might have changed) : > > > https://aur.archlinux.org/packages/thunderbird-beta/?setlang=en > > > > > > I'm mentioning this because at the moment it is noted as broken by > > > rustc-1.40.0. > > > > > > ĸen > > > > Good evening guys, > > > > Since we have LLVM-9 in the book now (since Sunday) and I had to leave the > > house for a bit today, I ran a build of rustc-1.37 with the following > > commit: > > > > https://github.com/rust-lang/rust/commit/04304fcd16e40c936dc5ba71c9ac3c445597f8bb > > > > I got past the LLVM build error, but now I have another one: > > > > Copying stage1 std from stage1 (x86_64-unknown-linux-gnu -> > > x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu) > > Building stage1 test artifacts (x86_64-unknown-linux-gnu -> > > x86_64-unknown-linux-gnu) > > Compiling proc_macro v0.0.0 (/sources/rustc-1.37.0-src/src/libproc_macro) > > error: Could not compile `proc_macro`. > > > > Caused by: > > process didn't exit successfully: > > `/sources/rustc-1.37.0-src/build/bootstrap/debug/rustc --edition=2018 > > --crate-name proc_macro src/libproc_macro/lib.rs --color always > > --error-format json --crate-type lib --emit=dep-info,metadata,link -C > > opt-level=2 -C metadata=b2a98432edc77a2f -C extra-filename=-b2a98432edc77a2f > > --out-dir /sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage1- > > test/x86_64-unknown-linux-gnu/release/deps > > --target x86_64-unknown-linux-gnu -L dependency=/sources/rustc-1.37.0- > > src/build/x86_64-unknown-linux-gnu/stage1-test/x86_64-unknown-linux- > > gnu/release/deps > > -L dependency=/sources/rustc-1.37.0-src/build/x86_64-unknown-linux- > > gnu/stage1-test/release/deps > > -C link-args=-lffi` (signal: 11, SIGSEGV: invalid memory reference) > > command did not execute successfully: > > "/sources/rustc-1.37.0-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo" > > "build" "--target" "x86_64-unknown-linux-gnu" "-j" "1" "--release" > > "--manifest-path" "/sources/rustc-1.37.0-src/src/libtest/Cargo.toml" > > "--message-format" "json" > > expected success, got: exit code: 101 > > failed to run: /sources/rustc-1.37.0-src/build/bootstrap/debug/bootstrap > > build --exclude src/tools/miri > > Build completed unsuccessfully in 0:00:05 > > > > I don't think that I"m doing anything differently from the book. I copied > > and pasted the stuff in there. > > > > One of the things that I dislike about Mozilla is that they expect the > > version of rustc to be the same across the entire lifecycle of an ESR > > release. From my interpretation of this thread, I think we only have a few > > options: > > > > I think that expectation is probably common in "enterprise" distros, > it's just unusual that we happen to explicitly use such versions > (thunderbird, and for convenience firefox). > > > 1 - Revert LLVM to 8.0.1 > > > > 2 - Force rustc to use it's internal LLVM version > > > > 3 - Backport the fix for rustc and LLVM, and then somehow fix the problems > > with proc_macro > > > > 4 - Update rustc, and then patch Thunderbird and Firefox (and potentially > > other consumers) > > > > I think the easiest will be number 2. I don't think we want to stay with > > LLVM-8 for the rest of this release cycle at least. Eventually we will > > encounter updates to Mesa and the like that may need a later LLVM. > > Backporting that fix is the second easiest solution, but we might have a > > chicken and egg problem with other rust consumers. IIRC the primary reason > > why we had to upgrade rustc last time was due to librsvg. > > > > - Doug > > > > No. 2 certainly sounds easier. The problem with no.4 is identifying > the remaining fix(es). I can't say that I like no.2, and for my own > usage (avoid llvm if possible, because gcc tends to have better > security options in its available flags) llvm-8.0.1 is fine. But > whether that is true in mesa releases before we release 9.1 is > unknown. > > The big problem with rust is its lack of stability - other compilers > deprecate things and then often remove them in a release or two, but > that typically means 6 months or a year - with rust two releases is > only about 12 weeks. > > BTW - since I've noted the time : Happy Xmas everyone.
I still perfer No. 3. There is a PR for LLVM-9 in rust repo: https://patch-diff.githubusercontent.com/raw/rust-lang/rust/pull/62474.patch -- Xi Ruoyao <xry...@mengyan1223.wang> School of Aerospace Science and Technology, Xidian University -- http://lists.linuxfromscratch.org/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
