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.
ĸen
--
We've all got both light and dark inside of us.
What matters is the part we choose to act on.
-- Sirius Black
--
http://lists.linuxfromscratch.org/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
