Introduction to Rust
The Rust programming language is designed
to be a safe, concurrent, practical language.
As with many other programming languages, rustc (the rust compiler)
needs a binary from which to bootstrap. It will download a stage0
binary at the start of the build, so you cannot compile it without an
Internet connection.
![[Note]](../images/note.png)
Note
Although BLFS usually installs in /usr, when you later upgrade to a newer
version of rust the old libraries in /usr/lib/rustlib will remain, with various
hashes in their names, but will not be usable and will waste space. The
editors recommend placing the files in the /opt directory. In particular, if you
have reason to rebuild with a modified configuration (e.g. using the
shipped LLVM after building with shared LLVM, perhaps to compile crates
for architectures which the BLFS LLVM build does not support)
it is possible for the install to leave a broken
cargo program. In such a situation, either remove
the existing installation first, or use a different prefix such as
/opt/rustc-1.91.0-build2.
If you prefer, you can of course change the prefix to /usr.
The current rustbuild build-system will use
all processors, although it does not scale well and often falls
back to just using one core while waiting for a library to compile.
However it can be mostly limited to a specified number of processors by
a combination of adding the switch --jobs <N>
(e.g. '--jobs 4' to limit to 4 processors) on each invocation of
./x.py and using an
environment variable CARGO_BUILD_JOBS=<N>. At the
moment this is not effective when some of the rustc tests are run.
The current version of rust's num_cpus crate now recognizes that cgroups
can be used to restrict which processors it is allowed to use. So if your
machine lacks DRAM (typically, less than 2 GB DRAM per core) that might be
an alternative to taking CPUs offline.
Read 'build-in-cgroup' for how to use a cgroup.
At the moment Rust does not provide any
guarantees of a stable ABI.
![[Note]](../images/note.png)
Note
Rustc defaults to building for ALL supported architectures, using a
shipped copy of LLVM. In BLFS the build is only for the X86
architecture.
If you intend to develop rust crates, this build may not be good
enough for your purposes.
The build times of this version when repeated on the same machine are
often reasonably consistent, but as with all compilations using
rustc there can be some very slow outliers.
This package is known to build and work properly
using an LFS 12.4 platform.
Package Information
Download (HTTP): https://static.rust-lang.org/dist/rustc-1.91.0-src.tar.xz
Download SHA256 Sum: 9b94161dba3aa32192e0e75f7891912d98095ffb86087b07a05af35a0265a938
Download MD5 sum: a97da33b52e5f879f4cabcf2ca727f5b
Download size: 259 MB
Estimated disk space required: 9.4 GB (252 MB installed); add 7.4 GB if running the tests
Estimated build time: 9.0 SBU (including download time; add 15 SBU for tests, both using parallelism=8)
Rust Dependencies
Required
CMake-4.1.3 and
cURL-8.17.0
Recommended
libssh2-1.11.1 and
LLVM-21.1.2
(built with -D LLVM_LINK_LLVM_DYLIB=ON so that rust can link to
system LLVM instead of building its shipped version)
![[Note]](../images/note.png)
Note
If a recommended dependency is not installed, you'll need to
modify the instructions to build and use a shipped copy in the
Rustc source tarball instead. See the Command Explanations section
for details.
Optional
git-2.52.0 (required by the test suite),
cranelift,
jemalloc,
and
libgit2
Editor Notes: https://wiki.linuxfromscratch.org/blfs/wiki/rust
Installation of Rust
To install into the
/opt directory, remove any
existing /opt/rustc symlink
and create a new directory (i.e. with a different name if trying a
modified build of the same version).
As the root user:
mkdir -pv /opt/rustc-1.91.0
ln -svfn rustc-1.91.0 /opt/rustc
![[Note]](../images/note.png)
Note
If multiple versions of Rust are installed
in /opt, changing to another
version only requires changing the /opt/rustc
symbolic link and then running ldconfig.
Create a suitable bootstrap.toml file which will
configure the build.
cat << EOF > bootstrap.toml
# See bootstrap.toml.example for more possible options,
# and see src/bootstrap/defaults/bootstrap.dist.toml for a few options
# automatically set when building from a release tarball
# (unfortunately, we have to override many of them).
# Tell x.py the editors have reviewed the content of this file
# and updated it to follow the major changes of the building system,
# so x.py will not warn us to do such a review.
change-id = 146435
[llvm]
# When using system llvm prefer shared libraries
link-shared = true
# If building the shipped LLVM source, only enable the x86 target
# instead of all the targets supported by LLVM.
targets = "X86"
[build]
description = "for BLFS r12.4-632"
# Omit docs to save time and space (default is to build them).
docs = false
# Do not query new versions of dependencies online.
locked-deps = true
# Specify which extended tools (those from the default install).
tools = ["cargo", "clippy", "rustdoc", "rustfmt"]
[install]
prefix = "/opt/rustc-1.91.0"
docdir = "share/doc/rustc-1.91.0"
[rust]
channel = "stable"
# Enable the same optimizations as the official upstream build.
lto = "thin"
codegen-units = 1
# Don't build llvm-bitcode-linker which is only useful for the NVPTX
# backend that we don't enable.
llvm-bitcode-linker = false
[target.x86_64-unknown-linux-gnu]
llvm-config = "/usr/bin/llvm-config"
[target.i686-unknown-linux-gnu]
llvm-config = "/usr/bin/llvm-config"
EOF
Compile Rust by running the following
commands:
export LIBSSH2_SYS_USE_PKG_CONFIG=1
export LIBSQLITE3_SYS_USE_PKG_CONFIG=1
./x.py build
![[Note]](../images/note.png)
Note
The test suite will generate some messages in the systemd journal
for traps on invalid opcodes, and for segmentation faults.
In themselves these are nothing to worry about, just a way for the
test to be terminated.
To run the tests (again using all available CPUs) issue:
./x.py test --verbose --no-fail-fast | tee rustc-testlog
The test named tests/run-make/rustdoc-target-modifiers
is known to fail because we've not enabled the AArch64 target in
LLVM-21.1.2.
As with all large test suites, some tests might fail on some machines -
if the number of additional failures is low,
check the log for 'failures:' and review lines above that, particularly the
'stderr:' lines. Any mention of
SIGSEGV or signal 11 in a failing test is a cause for concern.
![[Note]](../images/note.png)
Note
If you've stripped
/usr/lib/libc.a with
strip --strip-unneeded, all statically-linked
Rust programs will crash with SIGSEGV on start-up, causing several
tests (for example
tests/ui/process/nofile-limit.rs) to fail with
SIGSEGV.
It's caused by a Glibc bug affecting Glibc-2.42 and several prior
releases, so
for now we've replaced --strip-unneeded with
--strip-debug in both the LFS book and
the section called “Stripping” to work around the problem. If you hit
this issue, rebuild Glibc and replace the
/usr/lib/libc.a file
with the unstripped libc.a
from the fresh build.
If you get any other failing test which reports an
issue number then you should search for that issue. For example, when
rustc >= 1.41.1 was built with a version of sysllvm before 10.0 the test
for issue 69225 failed https://github.com/rust-lang/rust/issues/69225 and that should be
regarded as a critical failure (they released 1.41.1 because of it).
Most other failures will not be critical.
Therefore, you should determine the number of failures.
The number of tests which passed and failed can be found by running:
grep '^test result:' rustc-testlog |
awk '{sum1 += $4; sum2 += $6} END { print sum1 " passed; " sum2 " failed" }'
The other available fields are $8 for those which were ignored
(i.e. skipped), $10 for 'measured' and $12 for 'filtered out' but both
those last two are probably zero.
Now Install the package, as the root user:
![[Note]](../images/note.png)
Note
If sudo or su is invoked for
switching to the root user, ensure
LIBSSH2_SYS_USE_PKG_CONFIG and
LIBSQLITE3_SYS_USE_PKG_CONFIG are correctly passed or
the following command may rebuild cargo with
shipped copies of libssh2 and sqlite. For sudo,
use the
--preserve-env=LIB{SSH2,SQLITE3}_SYS_USE_PKG_CONFIG
option. For su, do not use
the - or --login options.
./x.py install
Still as the root user, fix the installation of documentation,
symlink a Zsh
completion file into the correct location, and move a
Bash completion file into the location
recommended by the Bash completion
maintainers:
rm -fv /opt/rustc-1.91.0/share/doc/rustc-1.91.0/*.old
install -vm644 README.md /opt/rustc-1.91.0/share/doc/rustc-1.91.0
install -vdm755 /usr/share/zsh/site-functions
ln -sfv /opt/rustc/share/zsh/site-functions/_cargo /usr/share/zsh/site-functions
mv -v /etc/bash_completion.d/cargo /usr/share/bash-completion/completions
Finally, unset the exported environment variables:
unset LIB{SSH2,SQLITE3}_SYS_USE_PKG_CONFIGCommand Explanations
ln -svfn rustc-1.91.0 /opt/rustc: if this is
not the first use of the /opt/rustc
symlink, overwrite it by forcing, and use the '-n' flag to avoid getting
confusing results from e.g. ls -l.
tools = ["cargo", "clippy", "rustdoc", "rustfmt"]:
only build the tools from the 'default' profile in binary command
rustup which are recommended for most users.
The other tools are unlikely to be useful unless using (old) code
analyzers or editing the standard library.
channel = "stable": this ensures only stable features
can be used, the default in bootstrap.toml is to use
development features, which is not appropriate for a released version.
[target.x86_64-unknown-linux-gnu]: the syntax of
bootstrap.toml requires an llvm-config
entry for each target for which system-llvm is to be used. Change the target
to [target.i686-unknown-linux-gnu] if you are building
on 32-bit x86. This whole section should be omitted if you wish to build
against the shipped llvm, but the resulting build will
be larger and take longer.
export LIBSSH2_SYS_USE_PKG_CONFIG=1: Allow
cargo to link to system libssh2. Omit this command
if you've not installed libssh2-1.11.1.
export LIBSQLITE3_SYS_USE_PKG_CONFIG=1: Allow
cargo to link to system sqlite.
--verbose: this switch can sometimes provide more
information about a test which fails.
--no-fail-fast: this switch ensures that the test suite
will not stop at the first error.