rustc-1.23.0-src

[ken@…]

Firefox-58 (due on around the 22nd of January) will need a newer rustc than what we have in the current book. To minimise the churn of rustc versions, I intend to use 1.23.0 (released last week).

Unfortunately, that does not build firefox-57.0.4 (it looks as if there is some problem with warning about unused variables), but it does build 58-beta14. So, it will have to go into the book with 58.0.

Meanwhile, I started a fresh build on one of my machines so that I could get more figures for time, space, test failures. But on the first attempt (without a log, because I built it fine on another machine last week) something failed in less than 6 minutes - but the original error seemed to have scrolled out.

I'm now doing a second attempt, using tee to capture the output. This appears to be building fine - unless the resulting log is enormous, I think I'll use a similar process in the book, so that people can find any error messages.

The claimed good feature of this release is that it uses less memory. I have no idea what difference that really makes.

[ken@…]

hmm, thought I'd already accepted this - I guess Meltdown and Spectre are breaking down my meagre brain power. aside: I'm really glad that clever people such as tglx are dealing with those!

Anyway, I've just built this on my new build (and then ff-58-beta) after two earlier builds, but the first attempt bailed (presumably non-zero status) after the actual 'build' step had apparently succeeded. I added an '

echo $?' to my script to try to work out WTF was going on, but that time it built successfully.

It seems to me that rustc continues to be painful.

[ken@…]

Realised I'd forgotten to measure the space used by ~/.cargo. Did a fresh build on a machine already running 1.23.0, then tried to DESTDIR as root (because we install as root, so cargo files may be added to /root/.cargo). Failed with bizarre errors.

I then did a clean build as myself, followed by attempt to DESTDIR as a user :

failed to execute command: "/tmp/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-config" "--version"
error: No such file or directory (os error 2)

But as I user I can happily run:

ken@plexi ~ $llvm-config --version
5.0.1

I loathe rust.

[bdubbs@…]

Rust builds it's own version of llvm. Interestingly, it is current: 5.0.1.

That is one of the reasons rust takes so long to build. llvm in the book is 22 SBU and rust is 33 SBU. If they used system llvm, it would be a LOT faster.

I'll note that I do have:

/tmp/rustc/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-config

but I generally do not do a DESTDIR install other than to look at files. In the case of rust, it seems to ignore the exported DESTDIR variable.

I note that I have:

$ du -sh .cargo 547M .cargo

Tell me again why upstream has gone to rustc/cargo?

[ken@…]

Replying to bdubbs@…:

Rust builds it's own version of llvm. Interestingly, it is current: 5.0.1.

That is one of the reasons rust takes so long to build. llvm in the book is 22 SBU and rust is 33 SBU. If they used system llvm, it would be a LOT faster.

The two problems in the past were:

1. Using system llvm, ISTR that tests failed excessively (but that was in the days before it reliably ran its full set of tests).

2. A version of rust which uses the current version of LLVM will always lag the introduction of the new LLVM to BLFS.

I'll note that I do have:

/tmp/rustc/rustc-1.23.0-src/build/x86_64-unknown-linux-gnu/llvm/bin/llvm-config

but I generally do not do a DESTDIR install other than to look at files. In the case of rust, it seems to ignore the exported DESTDIR variable.

I often use DESTDIR installs when looking at a new build. But I always do them manually, and specify the DESTDIR in the install command. But I now think that although rustc-1.23.0 had ended its build normally, something was missed. i.e. the reported completion at the end is inaccurate. I say that because I've just managed a successful user build and DESTDIR, but the build took a LOT longer than the previous abortive attempt.

Will run tests to check how much .cargo increases (if at all), then will give another try to getting root to do a DESTDIR.

My current feeling is that the build system is very flakey.

I note that I have:

$ du -sh .cargo 547M .cargo

Thanks, but I'd like to accurately blame rust / firefox / librsvg for cargo files!

Tell me again why upstream has gone to rustc/cargo?

o Because they like to make things harder for people who build from source

o Because they think everybody on supported platforms ought to use their binary builds

o Because they think rust will prevent a class of errors

o Because they want to ensure everybody uses the exact same versions of the cargo files, so that build-failures in the future cannot be worked around with current versions of the package

[ pick as many answers as you wish ]

[ken@…]

Still failed to DESTDIR as root, and the attempt took over 20 minutes (less than 7 minutes for a user DESTDIR install).

   Compiling error-chain v0.11.0
error: could not find native static library `ssh2`, perhaps an -L flag is missing?

error: Could not compile `libssh2-sys`.

That had only installed 329MB (of 426 MB). In a full reinstall (built, tested, and installed as root) that error-chain gets compiled while install is building stage2 cargo.

Repeating, same result. Added RUST_BACKTRACE=1 and eventually found the following some way before the failure:

-- Checking for module 'libcurl'
--   Found libcurl, version 7.57.0
-- Found OpenSSL: /usr/lib/libcrypto.so (found version "1.1.0g")
-- Could NOT find HTTP_Parser (missing: HTTP_PARSER_INCLUDE_DIR HTTP_PARSER_LIBRARY)
-- http-parser version 2 was not found; using bundled 3rd-party sources.
-- Found ZLIB: /usr/lib/libz.so (found version "1.2.11")
-- Checking for module 'libssh2'
--   No package 'libssh2' found
-- LIBSSH2 not found. Set CMAKE_PREFIX_PATH if it is installed outside of the default search path.

I guess libssh2 is ​https://github.com/libssh2/libssh2/releases but no idea why it suddenly want it.

At this point both my user and root each have 237 MB of files in their ~/.cargo directories. Which means that building as a user and then installing as root causes root to waste time downloading the same cargo files. <sigh/>

I know that building as root (which is what I normally do) successfully installs without that extra lib, and building as a user successfully runs a DESTDIR.

From there, trying to do a REAL install fails similarly - I'm now rebuilding rust as root to ensure nothing got installed in an incomplete state.

I think I'm going to say that people can build *as root* to save time and space, OR build as a user and do a DESTDIR install. Building as a user but installing as root will significantly extend the build while root downloads all the cargo files which the user has already downloaded, and rebuilds them.

If root tries to run a DESTDIR install, extra package(s) will be required.

This sucks rocks.

[bdubbs@…]

I did not build as root, but only installed as root.

   cat <<EOF > config.toml
# see src/bootstrap/config.toml.example for more possible options
[llvm]
targets = "X86"

[build]
# install cargo as well as rust
extended = true

[install]
prefix = "/usr"
docdir = "share/doc/rustc-1.23.0"
EOF

    export PYTHON=/usr/bin/python3

    #./x.py build --jobs 10  &&
    ./x.py build --jobs=10 &&

    #echo "BLFS Start CHECK"  &&
    #./x.py test --verbose --no-fail-fast &&

    echo "BLFS Start INSTALL"  &&
    #export DESTDIR=$DEST       &&
    $SUDO ./x.py install

The above did not install anything in the /root directory, but my regular user has a very large 0.5+ GB ~/.cargo directory. (Note SUDO='sudo -E')

Build completed successfully in 0:27:26
3432.4 Elapsed Time -  rustc-1.23.0-src
SBU=36.907
58604 /usr/src/rustc/rustc-1.23.0-src.tar.gz SIZE (57.230 MB)
3629044 kilobytes BUILD SIZE (3543.988 MB)
md5sum: 54a3ada73dd3239bb22e3a2de380d22c /usr/src/rustc/rustc-1.23.0-src.tar.gz

I did run into some problems with it indicating success without actually installing when I tried the export command above. The key to seeing if the install was complete is a few lines above where it has:

install: creating uninstall script at /usr/lib/rustlib/uninstall.sh

[ken@…]

I've had so many inconsistencies in building this version (in particularfailed builds which were fine when retried) that it gives me no confidence. Much of that was when using python3, but I think some of the failures happened before I found out that was possible.

1.22.1, using the stable channel, is more than new-enough for firefox-58.0, and is adequate for librsvg-2.42. I'll raise a separate ticket for that.

Meanwhile, 1.24 will be with us in 4 or 5 weeks. At the moment there is no *source* for firefox-59.0beta3 (the first available beta), but I'm going to stick my neck out and guess 1.22.1 will probably do for 59.0

Closing as WONTFIX.