rustc - do not update automatically

[ken@…]

A statement of a new policy for BLFS.

For the moment rustc and cargo are only in the book because firefox-53 requires them, although librsvg will need then on its next non-development release.

For firefox in particular, it is expected that newer versions of rust (that might actually mean cargo) will be required. But rust is a fairly heavy build and the release schedules for rust and cargo do not align with firefox releases.

To avoid users (particularly those not using workstations) unnecessarily rebuilding these packages, do not automatically upgrade either rust or cargo in the book.

For firefox, if time permits, I should be able to build a late beta to see if the version requirements have changed.

Cargo in itself is not particularly heavy, at least at the moment, but a newer release might require a newer rustc.

The downside of not automatically updating every (minor) version of cargo is that it may need to use a binary of the previous version, instead of bootstrapping from a (current or previous) self-compiled version. But my tests with current cargo suggest that bootstrapping afresh from a binary is quicker.

If rustc is changed to allow it to build against our current LLVM (so that we can drop separate LLVM3), or if vulnerabilities are discovered in rust, then upgrade. Otherwise, only upgrade when one of the packages using rustc or cargo requires a newer version.

Update: cargo has been shipped as part of rust for several releases, so tidy up the title by removing it.

[ken@…]

Two pieces of information: First, ff-54.0b3 builds successfully with the versions of rust and cargo in the book (I had to fix up one hunk of the patch to get it to apply), so at the moment what we have is good enough.

But second: on a quick look into the rustc-1.17.0 tarball last night I could not see *how* it determines if the system version of LLVM is adequate. In places there appear to be references to LLVM-4.0, so maybe they have already got onboard with that. I'm not of a mind to try to work out the details, but it raises a question: the next version of LLVM is expected to be 5.0, see ​http://blog.llvm.org/ - scroll down to Wednesday, December 14, 2016. But that is not due until September, so we perhaps have scope to archive the separate LLVM, alter 4.0 to build the required extra utils, and ship 8.1 like that (dep[ending on when it releases).

That all assumes that I'm right in guessing that rustc-1.17.0 can build against LLVM-4.0. At the moment I don't have enough interest in rust to handle the pain of trying to understand what changed in the build ;)

And for cargo I have no idea what changed - I couldn't even work out how it tested if rustc was adequate.

But for the moment, no requirement that we change anything.

[ken@…]

firefox-54.0b9 also builds ok with the versions in the book. Still three weeks to go before ff54 is released, but it looks as if we'll be ok.

[bdubbs@…]

Milestone renamed

[Wayne Blaszczyk]

I have not checked myself, but according to Arch, it looks like cargo has merged into rust (1.19).

[ken@…]

Well, we got three cycles of firefox from rustc-1.16.0. But for firefox-56 we will need a newer version (it says 1.17 would do). According to ​https://rusty-dash.com/ 1.20 will release on 1st September.

Perhaps now is a good time to upgrade to 1.19, to get it into our 8.1 release.

[ken@…]

Looking at the current 58.0b10, at least rust-1.21.0 is required. I had built that earlier for testing, but obviously not on the current system. It looks as if 1.22.1 is the latest rust (from reading the releases at rust in github), as always with the rustc downloads you need to know the version and add -src.tar.gz.

[ken@…]

Just a reminder for myself (or anybody else who follows this) - although current versions build when using PYTHON=/usr/bin/python3, the shipped configure wrapper (which we sidestep since it only creates configure.toml) really prefers python2, and some of the python scripts (possibly used for build, as well as for some of the tests) force python2.7 using /usr/bin/env.

Building with python3, 1.24.0 and 1.25.0 had appeared to work ok (I had had odd issues with 1.23.0), but in the last few hours I've seen more weirdness (my script exits after an apparently successful build). Using python2 I'm back in business.

[Bruce Dubbs]

Milestone renamed

[ken@…]

A reminder that seamonkey now also uses rustc. I think the whole list of users is now cbindgen, firefox, librsvg, seamonkey, thunderbird. Of those, seamonkey is probably going to be the one which is the biggest drag on using a newer version of rust.

[Douglas R. Reno]

Seamonkey has moved to gitlab (​https://gitlab.com/seamonkey-project) so it should at least be easier to get to when looking for patches

[ken@…]

A comment on the current state of play with newer rust versions:

1.39.0 is ok for firefox-68.6.0 and thunderbird-68.5.0, but not for seamonkey (details in the librsvg ticket, since that is what currently wants at least 1.39.0).

For later, 1.40.0 and 1.41.0 should not be used (if I read the issue which caused them to release 1.41.1 correctly, both were affected). 1.41.1 needs to use its shipped llvm until llvm-10 is released (the rust devs backported soemthign to fix their problem, and with our current system llvm the new test for the problem fails:

  [ui] ui/issues/issue-69225-SCEVAddExpr-wrap-flag.rs

Beyond that, 1.41.1 built with its shipepd llvm works fine for firefox-74.0, but on two attempts to compile firefox-68.6.0 it has left me with a blank Xorg display and an unusable machine.

[ken@…]

Bruce asked me if not automatically updating to latest version was still valid. I said that because the releases do not align with firefox there was no obvious reason to update, and plenty of potential breakage. But I also noted that a shipped crate in firefox-102.6.0 changed, with a comment that the new commit fixed an issue in rust-1.65.0, so I was minded to try it when I had time.

I've now done that. To my surprise, all the rust tests on my current system pass (I do not have gdb). That's a first. Firefox-102.6.0 did build on this (slow) test machine, but the build with only 4 cores online took an extra SBU. The build directory was 63MB smaller (same install size), but that is lost in the noise (rounds to 7.0GB instead of 7.1GB).

Looking at firefox-109.0 beta, the requirement is still rust >= 1.63.0 and I find it hard to justify using a newer version than 1.64.0, so I'll drop back to 1.64 when I build ff109beta, to save electricity.

Also, no idea how seamonkey would get on with a newer version (currently broken by python-3.11).

Oh, and rust-1.66.0 is nominally due today (Wednesday 15th).