rustc-1.25.0

[ken@…]

Firefox-60.0 (due in a bit over two weeks) needs a newer version of rustc than 1.22.0.

As Pierre noted in #10503 it would be good if we could use system llvm with rustc.

Not yet tested, my (limited) experience with 1.24.0 built with python3 suggested that version worked more reliably than 1.23.0, but it needs extended testing.

AFAICS, the next llvm major release should be after BLFS-8.3 so hopefully using system llvm might last for a few months.

At the moment I'm just building it (without tests) to look at ff60-beta and to then see how reliably my scripts run when I use it.

[ken@…]

In fact, the release date for firefox-60.0 is not until 9th May.

Also, need to determine if rustc-1.25.0 will build firefox-59-series.

[ken@…]

Replying to ken@…:

Also, need to determine if rustc-1.25.0 will build firefox-59-series.

I installed 1.25.0 (with its shipped llvm, built with python3) on this machine last night, so I used it to build 59.0.2, no problems. That means that if things continue ok (and provided it can also build librsvg) this could go into the book before firefox-60.

[ken@…]

I'm getting back to my "I really hate rust" state! About 24 hours ago I built 1.25.0 four times and installed it in /opt (three to confirm it would reliably build, although I noted the SBUs were variable, then a fourth time because I'd forgotten that the repeat script finished by wiping out /opt/rust.). And then I built firefox several times using /opt/rust/bin/rustc - an almost-complete build of 60-beta (I forgot that using my script would hide libcrmf.a, so that failed at the end), a build of 59.0.2, a vanilla manual build of -beta and then another with system graphite2 and harfbuzz

Things looked good, so I decided to upgrade this system to -beta in /usr, for which I wanted to install rustc-1.25.0 in /usr. Left it building rustc in X, came back to an 80x25 tty instead of the normal 100xWhatever tty, so I assumed it had rebooted to my nouveau-based first system on this machine (I'm now using a radeon). But no, the only reboot was when I then pressed Ctrl-Alt-Del. I'm retrying at the moment, it had failed during the rustc build and the syslog showed it had failed during stage2:

Apr  6 04:44:05 origin kernel: [32318.734501] traps: backtrace.stage[3292] trap invalid opcode ip:7f770d540498 sp:7fff8a04b2f0 error:0 in libstd-23815cc482a70678.so[7f770d4e6000+155000]
Apr  6 04:44:05 origin kernel: [32318.761267] traps: backtrace.stage[3305] trap invalid opcode ip:7f2a670f3498 sp:7ffdf2cd6060 error:0 in libstd-23815cc482a70678.so[7f2a67099000+155000]
Apr  6 04:47:48 origin kernel: [32541.823158] segfault-no-out[16965]: segfault at 0 ip 000055fd937ceb69 sp 00007fff8f94f100 error 6 in segfault-no-out-of-stack.stage2-x86_64-unknown-linux-gnu[55fd937cb000+5000]
Apr  6 04:47:55 origin kernel: [32548.615545] signal-exit-sta[17770]: segfault at 1 ip 000055cc448b9efc sp 00007fff3879c310 error 6 in signal-exit-status.stage2-x86_64-unknown-linux-gnu[55cc448b7000+4000]
Apr  6 04:47:58 origin kernel: [32551.276777] traps: simd-target-fea[18051] trap invalid opcode ip:562ab9dfc89c sp:7fff6be1eb50
error:0 in simd-target-feature-mixup.stage2-x86_64-unknown-linux-gnu[562ab9df9000+7000]

For the moment, my general view on rust is that it's more trouble than it's worth.

But compared to 1.23.0, at least this isn't a buildscript failing early but with status 0, this time it managed to crash Xorg. Not sure if that really counts as progress ;)

[ken@…]

Gave it another try, again it rebooted but this time I was more awake when I looked - the reboot was to the first ystem on the disk, so details of that boot were of course not in the log on the main system.

This time, looking at timestamps from my logs, the invalid opcodes happened at 06:37:48, which is shortly after it started to run the tests, and the segfaults about three and a half minutes later, but the tests continued for more than 20 minutes before the reboot - a chunk of nulls at the end of the log from the tests.

[ken@…]

I can't get past this, so I've raised ​https://github.com/rust-lang/rust/issues/49751

[ken@…]

Trying a build with system llvm : strangely, the build is no quicker, despite not having to compile the local llvm, but the log is a *lot* shorter as expected.

Interestingly, Arch seem to have moved away from using system llvm and are still using python2 to build rust. For fedora I can no longer find out how they build it (latest binaries for rawhide seem to have been updated recently, the previous links to thir srpm are dead and they have several pages of cgit matches for rust.

[ken@…]

Well, I _was_ making progress. Then I started looking at possible improvements in the build and my DESTDIR installs failed part-way. Will need to do a bit more testing.

Meanwhile, the installed version with its shipped llvm can build librsvg so that should not hold things up.

[ken@…]

Yesterday, fresh builds on my ryzen were working fine. Today (in my personal timezone :) they each rebooted during the tests. Eventually for other reasons (my buildscript exiting after the build, both on the ryzen and on another machine) I dropped back to using python2 and got a successful run of the tests.

So, while having gdb installed helps on ryzen it is not a panacea and you still have to ask yourself "Do I feel lucky?" if running the tests.

I will note that *all* builds report an error near the end of the build, miri fails to compile because of multiple potential crates for log. This is not anything to worry about (and you really do not want miri, it just adds space and time and the tests it enables are disabled by default).

After some more testing (build and reinstall librsvg on rustc built with system llvm, test some of its users) I intend to show a DESTDIR install for this, followed by root installing by copying, to allow building as a user without root having to download and compile all the cargo files for the install. That should be cleaner than what is currently in the book (a benefit of updating rust before it becomes imperative for firefox, with time to review the options). The disk space DOES go up like that, of course, but 1.25 seems to be bigger than 1.22 (no surprise there) and the DESTDIR+system-llvm space is smaller than the space used by the source files (after running tests) if using the shipped llvm

I've also tested rustc, and then firefox-60beta, on an 8.2 system where llvm was 5.0.1 and the build with system llvm worked fine (got that from slackbuilds!). But using system llvm is messy, e.g. when config.toml is parsed, the text specifying llvm-config seems to be executed even if it has been commented (the resulting config.toml is ok, but the 'help' output from llvm-config appears on screen.

Hmm, checking the space, I realise I need to remeasure without running the tests. </sigh>

[ken@…]

r20084.