604 lines
38 KiB
HTML
604 lines
38 KiB
HTML
<!DOCTYPE HTML>
|
|
<html lang="en" class="light sidebar-visible" dir="ltr">
|
|
<head>
|
|
<!-- Book generated using mdBook -->
|
|
<meta charset="UTF-8">
|
|
<title>What Bootstrapping does - Rust Compiler Development Guide</title>
|
|
|
|
|
|
<!-- Custom HTML head -->
|
|
|
|
<meta name="description" content="A guide to developing the Rust compiler (rustc)">
|
|
<meta name="viewport" content="width=device-width, initial-scale=1">
|
|
<meta name="theme-color" content="#ffffff">
|
|
|
|
<link rel="icon" href="../../favicon.svg">
|
|
<link rel="shortcut icon" href="../../favicon.png">
|
|
<link rel="stylesheet" href="../../css/variables.css">
|
|
<link rel="stylesheet" href="../../css/general.css">
|
|
<link rel="stylesheet" href="../../css/chrome.css">
|
|
<link rel="stylesheet" href="../../css/print.css" media="print">
|
|
|
|
<!-- Fonts -->
|
|
<link rel="stylesheet" href="../../FontAwesome/css/font-awesome.css">
|
|
<link rel="stylesheet" href="../../fonts/fonts.css">
|
|
|
|
<!-- Highlight.js Stylesheets -->
|
|
<link rel="stylesheet" id="highlight-css" href="../../highlight.css">
|
|
<link rel="stylesheet" id="tomorrow-night-css" href="../../tomorrow-night.css">
|
|
<link rel="stylesheet" id="ayu-highlight-css" href="../../ayu-highlight.css">
|
|
|
|
<!-- Custom theme stylesheets -->
|
|
|
|
|
|
<!-- Provide site root and default themes to javascript -->
|
|
<script>
|
|
const path_to_root = "../../";
|
|
const default_light_theme = "light";
|
|
const default_dark_theme = "navy";
|
|
</script>
|
|
<!-- Start loading toc.js asap -->
|
|
<script src="../../toc.js"></script>
|
|
</head>
|
|
<body>
|
|
<div id="body-container">
|
|
<!-- Work around some values being stored in localStorage wrapped in quotes -->
|
|
<script>
|
|
try {
|
|
let theme = localStorage.getItem('mdbook-theme');
|
|
let sidebar = localStorage.getItem('mdbook-sidebar');
|
|
|
|
if (theme.startsWith('"') && theme.endsWith('"')) {
|
|
localStorage.setItem('mdbook-theme', theme.slice(1, theme.length - 1));
|
|
}
|
|
|
|
if (sidebar.startsWith('"') && sidebar.endsWith('"')) {
|
|
localStorage.setItem('mdbook-sidebar', sidebar.slice(1, sidebar.length - 1));
|
|
}
|
|
} catch (e) { }
|
|
</script>
|
|
|
|
<!-- Set the theme before any content is loaded, prevents flash -->
|
|
<script>
|
|
const default_theme = window.matchMedia("(prefers-color-scheme: dark)").matches ? default_dark_theme : default_light_theme;
|
|
let theme;
|
|
try { theme = localStorage.getItem('mdbook-theme'); } catch(e) { }
|
|
if (theme === null || theme === undefined) { theme = default_theme; }
|
|
const html = document.documentElement;
|
|
html.classList.remove('light')
|
|
html.classList.add(theme);
|
|
html.classList.add("js");
|
|
</script>
|
|
|
|
<input type="checkbox" id="sidebar-toggle-anchor" class="hidden">
|
|
|
|
<!-- Hide / unhide sidebar before it is displayed -->
|
|
<script>
|
|
let sidebar = null;
|
|
const sidebar_toggle = document.getElementById("sidebar-toggle-anchor");
|
|
if (document.body.clientWidth >= 1080) {
|
|
try { sidebar = localStorage.getItem('mdbook-sidebar'); } catch(e) { }
|
|
sidebar = sidebar || 'visible';
|
|
} else {
|
|
sidebar = 'hidden';
|
|
}
|
|
sidebar_toggle.checked = sidebar === 'visible';
|
|
html.classList.remove('sidebar-visible');
|
|
html.classList.add("sidebar-" + sidebar);
|
|
</script>
|
|
|
|
<nav id="sidebar" class="sidebar" aria-label="Table of contents">
|
|
<!-- populated by js -->
|
|
<mdbook-sidebar-scrollbox class="sidebar-scrollbox"></mdbook-sidebar-scrollbox>
|
|
<noscript>
|
|
<iframe class="sidebar-iframe-outer" src="../../toc.html"></iframe>
|
|
</noscript>
|
|
<div id="sidebar-resize-handle" class="sidebar-resize-handle">
|
|
<div class="sidebar-resize-indicator"></div>
|
|
</div>
|
|
</nav>
|
|
|
|
<div id="page-wrapper" class="page-wrapper">
|
|
|
|
<div class="page">
|
|
<div id="menu-bar-hover-placeholder"></div>
|
|
<div id="menu-bar" class="menu-bar sticky">
|
|
<div class="left-buttons">
|
|
<label id="sidebar-toggle" class="icon-button" for="sidebar-toggle-anchor" title="Toggle Table of Contents" aria-label="Toggle Table of Contents" aria-controls="sidebar">
|
|
<i class="fa fa-bars"></i>
|
|
</label>
|
|
<button id="theme-toggle" class="icon-button" type="button" title="Change theme" aria-label="Change theme" aria-haspopup="true" aria-expanded="false" aria-controls="theme-list">
|
|
<i class="fa fa-paint-brush"></i>
|
|
</button>
|
|
<ul id="theme-list" class="theme-popup" aria-label="Themes" role="menu">
|
|
<li role="none"><button role="menuitem" class="theme" id="default_theme">Auto</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="light">Light</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="rust">Rust</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="coal">Coal</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="navy">Navy</button></li>
|
|
<li role="none"><button role="menuitem" class="theme" id="ayu">Ayu</button></li>
|
|
</ul>
|
|
<button id="search-toggle" class="icon-button" type="button" title="Search. (Shortkey: s)" aria-label="Toggle Searchbar" aria-expanded="false" aria-keyshortcuts="S" aria-controls="searchbar">
|
|
<i class="fa fa-search"></i>
|
|
</button>
|
|
</div>
|
|
|
|
<h1 class="menu-title">Rust Compiler Development Guide</h1>
|
|
|
|
<div class="right-buttons">
|
|
<a href="../../print.html" title="Print this book" aria-label="Print this book">
|
|
<i id="print-button" class="fa fa-print"></i>
|
|
</a>
|
|
<a href="https://github.com/rust-lang/rustc-dev-guide" title="Git repository" aria-label="Git repository">
|
|
<i id="git-repository-button" class="fa fa-github"></i>
|
|
</a>
|
|
<a href="https://github.com/rust-lang/rustc-dev-guide/edit/master/src/building/bootstrapping/what-bootstrapping-does.md" title="Suggest an edit" aria-label="Suggest an edit">
|
|
<i id="git-edit-button" class="fa fa-edit"></i>
|
|
</a>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
<div id="search-wrapper" class="hidden">
|
|
<form id="searchbar-outer" class="searchbar-outer">
|
|
<input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header">
|
|
</form>
|
|
<div id="searchresults-outer" class="searchresults-outer hidden">
|
|
<div id="searchresults-header" class="searchresults-header"></div>
|
|
<ul id="searchresults">
|
|
</ul>
|
|
</div>
|
|
</div>
|
|
|
|
<!-- Apply ARIA attributes after the sidebar and the sidebar toggle button are added to the DOM -->
|
|
<script>
|
|
document.getElementById('sidebar-toggle').setAttribute('aria-expanded', sidebar === 'visible');
|
|
document.getElementById('sidebar').setAttribute('aria-hidden', sidebar !== 'visible');
|
|
Array.from(document.querySelectorAll('#sidebar a')).forEach(function(link) {
|
|
link.setAttribute('tabIndex', sidebar === 'visible' ? 0 : -1);
|
|
});
|
|
</script>
|
|
|
|
<div id="content" class="content">
|
|
<main>
|
|
<h1 id="what-bootstrapping-does"><a class="header" href="#what-bootstrapping-does">What Bootstrapping does</a></h1>
|
|
<ul>
|
|
<li><a href="#stages-of-bootstrapping">Stages of bootstrapping</a>
|
|
<ul>
|
|
<li><a href="#overview">Overview</a></li>
|
|
<li><a href="#stage-0-the-pre-compiled-compiler">Stage 0: the pre-compiled compiler</a></li>
|
|
<li><a href="#stage-1-from-current-code-by-an-earlier-compiler">Stage 1: from current code, by an earlier compiler</a></li>
|
|
<li><a href="#stage-2-the-truly-current-compiler">Stage 2: the truly current compiler</a></li>
|
|
<li><a href="#stage-3-the-same-result-test">Stage 3: the same-result test</a></li>
|
|
<li><a href="#building-the-stages">Building the stages</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#complications-of-bootstrapping">Complications of bootstrapping</a></li>
|
|
<li><a href="#understanding-stages-of-bootstrap">Understanding stages of bootstrap</a>
|
|
<ul>
|
|
<li><a href="#overview-1">Overview</a>
|
|
<ul>
|
|
<li><a href="#build-artifacts">Build artifacts</a></li>
|
|
<li><a href="#examples">Examples</a></li>
|
|
<li><a href="#examples-of-what-not-to-do">Examples of what not to do</a></li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#building-vs-running">Building vs. running</a></li>
|
|
<li><a href="#stages-and-std">Stages and <code>std</code></a></li>
|
|
<li><a href="#cross-compiling-rustc">Cross-compiling rustc</a></li>
|
|
<li><a href="#what-is-a-sysroot">What is a 'sysroot'?</a>
|
|
<ul>
|
|
<li><a href="#-z-force-unstable-if-unmarked"><code>-Z force-unstable-if-unmarked</code></a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li><a href="#passing-flags-to-commands-invoked-by-bootstrap">Passing flags to commands invoked by <code>bootstrap</code></a></li>
|
|
<li><a href="#environment-variables">Environment Variables</a></li>
|
|
<li><a href="#clarification-of-build-commands-stdout">Clarification of build command's <code>stdout</code></a>
|
|
<ul>
|
|
<li><a href="#building-stage0-stdcompiler-artifacts">Building stage0 {std,compiler} artifacts</a></li>
|
|
<li><a href="#copying-stage0-stdrustc">Copying stage0 {std,rustc}</a></li>
|
|
<li><a href="#assembling-stage1-compiler">Assembling stage1 compiler</a></li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
<p><a href="https://en.wikipedia.org/wiki/Bootstrapping_(compilers)"><em>Bootstrapping</em></a> is the process of using a compiler to compile itself.
|
|
More accurately, it means using an older compiler to compile a newer version of
|
|
the same compiler.</p>
|
|
<p>This raises a chicken-and-egg paradox: where did the first compiler come from?
|
|
It must have been written in a different language. In Rust's case it was
|
|
<a href="https://github.com/rust-lang/rust/tree/ef75860a0a72f79f97216f8aaa5b388d98da6480/src/boot">written in OCaml</a>. However, it was abandoned long ago, and the
|
|
only way to build a modern version of <code>rustc</code> is with a slightly less modern version.</p>
|
|
<p>This is exactly how <a href="https://github.com/rust-lang/rust/blob/master/x.py"><code>./x.py</code></a> works: it downloads the current beta release of
|
|
<code>rustc</code>, then uses it to compile the new compiler.</p>
|
|
<p>Note that this documentation mostly covers user-facing information. See
|
|
<a href="https://github.com/rust-lang/rust/blob/master/src/bootstrap/README.md">bootstrap/README.md</a> to read about bootstrap internals.</p>
|
|
<h2 id="stages-of-bootstrapping"><a class="header" href="#stages-of-bootstrapping">Stages of bootstrapping</a></h2>
|
|
<h3 id="overview"><a class="header" href="#overview">Overview</a></h3>
|
|
<ul>
|
|
<li>Stage 0: the pre-compiled compiler</li>
|
|
<li>Stage 1: from current code, by an earlier compiler</li>
|
|
<li>Stage 2: the truly current compiler</li>
|
|
<li>Stage 3: the same-result test</li>
|
|
</ul>
|
|
<p>Compiling <code>rustc</code> is done in stages. Here's a diagram, adapted from Jynn
|
|
Nelson's <a href="https://www.youtube.com/watch?v=oUIjG-y4zaA">talk on bootstrapping</a> at RustConf 2022, with
|
|
detailed explanations below.</p>
|
|
<p>The <code>A</code>, <code>B</code>, <code>C</code>, and <code>D</code> show the ordering of the stages of bootstrapping.
|
|
<span style="background-color: lightblue; color: black">Blue</span> nodes are
|
|
downloaded, <span style="background-color: yellow; color: black">yellow</span>
|
|
nodes are built with the <code>stage0</code> compiler, and <span style="background-color:
|
|
lightgreen; color: black">green</span> nodes are built with the <code>stage1</code>
|
|
compiler.</p>
|
|
<pre class="mermaid">graph TD
|
|
s0c["stage0 compiler (1.86.0-beta.1)"]:::downloaded -->|A| s0l("stage0 std (1.86.0-beta.1)"):::downloaded;
|
|
s0c & s0l --- stepb[ ]:::empty;
|
|
stepb -->|B| s0ca["stage0 compiler artifacts (1.87.0-dev)"]:::with-s0c;
|
|
s0ca -->|copy| s1c["stage1 compiler (1.87.0-dev)"]:::with-s0c;
|
|
s1c -->|C| s1l("stage1 std (1.87.0-dev)"):::with-s1c;
|
|
s1c & s1l --- stepd[ ]:::empty;
|
|
stepd -->|D| s1ca["stage1 compiler artifacts (1.87.0-dev)"]:::with-s1c;
|
|
s1ca -->|copy| s2c["stage2 compiler"]:::with-s1c;
|
|
|
|
classDef empty width:0px,height:0px;
|
|
classDef downloaded fill: lightblue;
|
|
classDef with-s0c fill: yellow;
|
|
classDef with-s1c fill: lightgreen;
|
|
</pre>
|
|
<h3 id="stage-0-the-pre-compiled-compiler"><a class="header" href="#stage-0-the-pre-compiled-compiler">Stage 0: the pre-compiled compiler</a></h3>
|
|
<p>The stage0 compiler is by default the very recent <em>beta</em> <code>rustc</code> compiler and its
|
|
associated dynamic libraries, which <code>./x.py</code> will download for you. (You can
|
|
also configure <code>./x.py</code> to change stage0 to something else.)</p>
|
|
<p>The precompiled stage0 compiler is then used only to compile <a href="https://github.com/rust-lang/rust/tree/master/src/bootstrap"><code>src/bootstrap</code></a> and <a href="https://github.com/rust-lang/rust/tree/master/compiler/rustc"><code>compiler/rustc</code></a>
|
|
with precompiled stage0 std.</p>
|
|
<p>Note that to build the stage1 compiler we use the precompiled stage0 compiler and std.
|
|
Therefore, to use a compiler with a std that is freshly built from the tree, you need to
|
|
build the stage2 compiler.</p>
|
|
<p>There are two concepts at play here: a compiler (with its set of dependencies) and its
|
|
'target' or 'object' libraries (<code>std</code> and <code>rustc</code>). Both are staged, but in a staggered manner.</p>
|
|
<h3 id="stage-1-from-current-code-by-an-earlier-compiler"><a class="header" href="#stage-1-from-current-code-by-an-earlier-compiler">Stage 1: from current code, by an earlier compiler</a></h3>
|
|
<p>The rustc source code is then compiled with the <code>stage0</code> compiler to produce the
|
|
<code>stage1</code> compiler.</p>
|
|
<h3 id="stage-2-the-truly-current-compiler"><a class="header" href="#stage-2-the-truly-current-compiler">Stage 2: the truly current compiler</a></h3>
|
|
<p>We then rebuild the compiler using <code>stage1</code> compiler with in-tree std to produce the <code>stage2</code>
|
|
compiler.</p>
|
|
<p>The <code>stage1</code> compiler itself was built by precompiled <code>stage0</code> compiler and std
|
|
and hence not by the source in your working directory. This means that the ABI
|
|
generated by the <code>stage0</code> compiler may not match the ABI that would have been made
|
|
by the <code>stage1</code> compiler, which can cause problems for dynamic libraries, tests
|
|
and tools using <code>rustc_private</code>.</p>
|
|
<p>Note that the <code>proc_macro</code> crate avoids this issue with a <code>C</code> FFI layer called
|
|
<code>proc_macro::bridge</code>, allowing it to be used with <code>stage1</code>.</p>
|
|
<p>The <code>stage2</code> compiler is the one distributed with <code>rustup</code> and all other install
|
|
methods. However, it takes a very long time to build because one must first
|
|
build the new compiler with an older compiler and then use that to build the new
|
|
compiler with itself.</p>
|
|
<p>For development, you usually only want to use <code>--stage 1</code> flag to build things.
|
|
See <a href="../how-to-build-and-run.html#building-the-compiler">Building the compiler</a>.</p>
|
|
<h3 id="stage-3-the-same-result-test"><a class="header" href="#stage-3-the-same-result-test">Stage 3: the same-result test</a></h3>
|
|
<p>Stage 3 is optional. To sanity check our new compiler we can build the libraries
|
|
with the <code>stage2</code> compiler. The result ought to be identical to before, unless
|
|
something has broken.</p>
|
|
<h3 id="building-the-stages"><a class="header" href="#building-the-stages">Building the stages</a></h3>
|
|
<p>The script <a href="https://github.com/rust-lang/rust/blob/master/x"><code>./x</code></a> tries to be helpful and pick the stage you most likely meant
|
|
for each subcommand. Here are some <code>x</code> commands with their default stages:</p>
|
|
<ul>
|
|
<li><code>check</code>: <code>--stage 1</code></li>
|
|
<li><code>clippy</code>: <code>--stage 1</code></li>
|
|
<li><code>doc</code>: <code>--stage 1</code></li>
|
|
<li><code>build</code>: <code>--stage 1</code></li>
|
|
<li><code>test</code>: <code>--stage 1</code></li>
|
|
<li><code>dist</code>: <code>--stage 2</code></li>
|
|
<li><code>install</code>: <code>--stage 2</code></li>
|
|
<li><code>bench</code>: <code>--stage 2</code></li>
|
|
</ul>
|
|
<p>You can always override the stage by passing <code>--stage N</code> explicitly.</p>
|
|
<p>For more information about stages, <a href="#understanding-stages-of-bootstrap">see
|
|
below</a>.</p>
|
|
<h2 id="complications-of-bootstrapping"><a class="header" href="#complications-of-bootstrapping">Complications of bootstrapping</a></h2>
|
|
<p>Since the build system uses the current beta compiler to build a <code>stage1</code>
|
|
bootstrapping compiler, the compiler source code can't use some features until
|
|
they reach beta (because otherwise the beta compiler doesn't support them). On
|
|
the other hand, for <a href="../../appendix/glossary.html#intrinsic">compiler intrinsics</a> and internal features, the
|
|
features <em>have</em> to be used. Additionally, the compiler makes heavy use of
|
|
<code>nightly</code> features (<code>#![feature(...)]</code>). How can we resolve this problem?</p>
|
|
<p>There are two methods used:</p>
|
|
<ol>
|
|
<li>The build system sets <code>--cfg bootstrap</code> when building with <code>stage0</code>, so we
|
|
can use <code>cfg(not(bootstrap))</code> to only use features when built with <code>stage1</code>.
|
|
Setting <code>--cfg bootstrap</code> in this way is used for features that were just
|
|
stabilized, which require <code>#![feature(...)]</code> when built with <code>stage0</code>, but
|
|
not for <code>stage1</code>.</li>
|
|
<li>The build system sets <code>RUSTC_BOOTSTRAP=1</code>. This special variable means to
|
|
<em>break the stability guarantees</em> of Rust: allowing use of <code>#![feature(...)]</code>
|
|
with a compiler that's not <code>nightly</code>. <em>Setting <code>RUSTC_BOOTSTRAP=1</code> should
|
|
never be used except when bootstrapping the compiler.</em></li>
|
|
</ol>
|
|
<h2 id="understanding-stages-of-bootstrap"><a class="header" href="#understanding-stages-of-bootstrap">Understanding stages of bootstrap</a></h2>
|
|
<h3 id="overview-1"><a class="header" href="#overview-1">Overview</a></h3>
|
|
<p>This is a detailed look into the separate bootstrap stages.</p>
|
|
<p>The convention <code>./x</code> uses is that:</p>
|
|
<ul>
|
|
<li>A <code>--stage N</code> flag means to run the stage N compiler (<code>stageN/rustc</code>).</li>
|
|
<li>A "stage N artifact" is a build artifact that is <em>produced</em> by the stage N
|
|
compiler.</li>
|
|
<li>The stage N+1 compiler is assembled from stage N <em>artifacts</em>. This process is
|
|
called <em>uplifting</em>.</li>
|
|
</ul>
|
|
<h4 id="build-artifacts"><a class="header" href="#build-artifacts">Build artifacts</a></h4>
|
|
<p>Anything you can build with <code>./x</code> is a <em>build artifact</em>. Build artifacts
|
|
include, but are not limited to:</p>
|
|
<ul>
|
|
<li>binaries, like <code>stage0-rustc/rustc-main</code></li>
|
|
<li>shared objects, like <code>stage0-sysroot/rustlib/libstd-6fae108520cf72fe.so</code></li>
|
|
<li><a href="../../serialization.html">rlib</a> files, like <code>stage0-sysroot/rustlib/libstd-6fae108520cf72fe.rlib</code></li>
|
|
<li>HTML files generated by rustdoc, like <code>doc/std</code></li>
|
|
</ul>
|
|
<h4 id="examples"><a class="header" href="#examples">Examples</a></h4>
|
|
<ul>
|
|
<li><code>./x test tests/ui</code> means to build the <code>stage1</code> compiler and run <code>compiletest</code>
|
|
on it. If you're working on the compiler, this is normally the test command
|
|
you want.</li>
|
|
<li><code>./x test --stage 0 library/std</code> means to run tests on the standard library
|
|
without building <code>rustc</code> from source ('build with <code>stage0</code>, then test the
|
|
artifacts'). If you're working on the standard library, this is normally the
|
|
test command you want.</li>
|
|
<li><code>./x build --stage 0</code> means to build with the stage0 <code>rustc</code>.</li>
|
|
<li><code>./x doc --stage 0</code> means to document using the stage0 <code>rustdoc</code>.</li>
|
|
</ul>
|
|
<h4 id="examples-of-what-not-to-do"><a class="header" href="#examples-of-what-not-to-do">Examples of what <em>not</em> to do</a></h4>
|
|
<ul>
|
|
<li><code>./x test --stage 0 tests/ui</code> is not useful: it runs tests on the <em>beta</em>
|
|
compiler and doesn't build <code>rustc</code> from source. Use <code>test tests/ui</code> instead,
|
|
which builds <code>stage1</code> from source.</li>
|
|
<li><code>./x test --stage 0 compiler/rustc</code> builds the compiler but runs no tests:
|
|
it's running <code>cargo test -p rustc</code>, but <code>cargo</code> doesn't understand Rust's
|
|
tests. You shouldn't need to use this, use <code>test</code> instead (without arguments).</li>
|
|
<li><code>./x build --stage 0 compiler/rustc</code> builds the compiler, but does not build
|
|
<code>libstd</code> or even <code>libcore</code>. Most of the time, you'll want <code>./x build library</code>
|
|
instead, which allows compiling programs without needing to define lang items.</li>
|
|
</ul>
|
|
<h3 id="building-vs-running"><a class="header" href="#building-vs-running">Building vs. running</a></h3>
|
|
<p>In short, <em>stage 0 uses the <code>stage0</code> compiler to create <code>stage0</code> artifacts which
|
|
will later be uplifted to be the stage1 compiler</em>.</p>
|
|
<p>In each stage, two major steps are performed:</p>
|
|
<ol>
|
|
<li><code>std</code> is compiled by the stage N compiler.</li>
|
|
<li>That <code>std</code> is linked to programs built by the stage N compiler, including the
|
|
stage N artifacts (stage N+1 compiler).</li>
|
|
</ol>
|
|
<p>This is somewhat intuitive if one thinks of the stage N artifacts as "just"
|
|
another program we are building with the stage N compiler: <code>build --stage N compiler/rustc</code> is linking the stage N artifacts to the <code>std</code> built by the stage
|
|
N compiler.</p>
|
|
<h3 id="stages-and-std"><a class="header" href="#stages-and-std">Stages and <code>std</code></a></h3>
|
|
<p>Note that there are two <code>std</code> libraries in play here:</p>
|
|
<ol>
|
|
<li>The library <em>linked</em> to <code>stageN/rustc</code>, which was built by stage N-1 (stage
|
|
N-1 <code>std</code>)</li>
|
|
<li>The library <em>used to compile programs</em> with <code>stageN/rustc</code>, which was built
|
|
by stage N (stage N <code>std</code>).</li>
|
|
</ol>
|
|
<p>Stage N <code>std</code> is pretty much necessary for any useful work with the stage N
|
|
compiler. Without it, you can only compile programs with <code>#![no_core]</code> -- not
|
|
terribly useful!</p>
|
|
<p>The reason these need to be different is because they aren't necessarily
|
|
ABI-compatible: there could be new layout optimizations, changes to <code>MIR</code>, or
|
|
other changes to Rust metadata on <code>nightly</code> that aren't present in beta.</p>
|
|
<p>This is also where <code>--keep-stage 1 library/std</code> comes into play. Since most
|
|
changes to the compiler don't actually change the ABI, once you've produced a
|
|
<code>std</code> in <code>stage1</code>, you can probably just reuse it with a different compiler. If
|
|
the ABI hasn't changed, you're good to go, no need to spend time recompiling
|
|
that <code>std</code>. The flag <code>--keep-stage</code> simply instructs the build script to assumes
|
|
the previous compile is fine and copies those artifacts into the appropriate
|
|
place, skipping the <code>cargo</code> invocation.</p>
|
|
<h3 id="cross-compiling-rustc"><a class="header" href="#cross-compiling-rustc">Cross-compiling rustc</a></h3>
|
|
<p><em>Cross-compiling</em> is the process of compiling code that will run on another
|
|
architecture. For instance, you might want to build an ARM version of rustc
|
|
using an x86 machine. Building <code>stage2</code> <code>std</code> is different when you are
|
|
cross-compiling.</p>
|
|
<p>This is because <code>./x</code> uses the following logic: if <code>HOST</code> and <code>TARGET</code> are the
|
|
same, it will reuse <code>stage1</code> <code>std</code> for <code>stage2</code>! This is sound because <code>stage1</code>
|
|
<code>std</code> was compiled with the <code>stage1</code> compiler, i.e. a compiler using the source
|
|
code you currently have checked out. So it should be identical (and therefore
|
|
ABI-compatible) to the <code>std</code> that <code>stage2/rustc</code> would compile.</p>
|
|
<p>However, when cross-compiling, <code>stage1</code> <code>std</code> will only run on the host. So the
|
|
<code>stage2</code> compiler has to recompile <code>std</code> for the target.</p>
|
|
<p>(See in the table how <code>stage2</code> only builds non-host <code>std</code> targets).</p>
|
|
<h3 id="what-is-a-sysroot"><a class="header" href="#what-is-a-sysroot">What is a 'sysroot'?</a></h3>
|
|
<p>When you build a project with <code>cargo</code>, the build artifacts for dependencies are
|
|
normally stored in <code>target/debug/deps</code>. This only contains dependencies <code>cargo</code>
|
|
knows about; in particular, it doesn't have the standard library. Where do <code>std</code>
|
|
or <code>proc_macro</code> come from? They come from the <strong>sysroot</strong>, the root of a number
|
|
of directories where the compiler loads build artifacts at runtime. The
|
|
<code>sysroot</code> doesn't just store the standard library, though - it includes anything
|
|
that needs to be loaded at runtime. That includes (but is not limited to):</p>
|
|
<ul>
|
|
<li>Libraries <code>libstd</code>/<code>libtest</code>/<code>libproc_macro</code>.</li>
|
|
<li>Compiler crates themselves, when using <code>rustc_private</code>. In-tree these are
|
|
always present; out of tree, you need to install <code>rustc-dev</code> with <code>rustup</code>.</li>
|
|
<li>Shared object file <code>libLLVM.so</code> for the LLVM project. In-tree this is either
|
|
built from source or downloaded from CI; out-of-tree, you need to install
|
|
<code>llvm-tools-preview</code> with <code>rustup</code>.</li>
|
|
</ul>
|
|
<p>All the artifacts listed so far are <em>compiler</em> runtime dependencies. You can see
|
|
them with <code>rustc --print sysroot</code>:</p>
|
|
<pre><code>$ ls $(rustc --print sysroot)/lib
|
|
libchalk_derive-0685d79833dc9b2b.so libstd-25c6acf8063a3802.so
|
|
libLLVM-11-rust-1.50.0-nightly.so libtest-57470d2aa8f7aa83.so
|
|
librustc_driver-4f0cc9f50e53f0ba.so libtracing_attributes-e4be92c35ab2a33b.so
|
|
librustc_macros-5f0ec4a119c6ac86.so rustlib
|
|
</code></pre>
|
|
<p>There are also runtime dependencies for the standard library! These are in
|
|
<code>lib/rustlib/</code>, not <code>lib/</code> directly.</p>
|
|
<pre><code>$ ls $(rustc --print sysroot)/lib/rustlib/x86_64-unknown-linux-gnu/lib | head -n 5
|
|
libaddr2line-6c8e02b8fedc1e5f.rlib
|
|
libadler-9ef2480568df55af.rlib
|
|
liballoc-9c4002b5f79ba0e1.rlib
|
|
libcfg_if-512eb53291f6de7e.rlib
|
|
libcompiler_builtins-ef2408da76957905.rlib
|
|
</code></pre>
|
|
<p>Directory <code>lib/rustlib/</code> includes libraries like <code>hashbrown</code> and <code>cfg_if</code>, which
|
|
are not part of the public API of the standard library, but are used to
|
|
implement it. Also <code>lib/rustlib/</code> is part of the search path for linkers, but
|
|
<code>lib</code> will never be part of the search path.</p>
|
|
<h4 id="-z-force-unstable-if-unmarked"><a class="header" href="#-z-force-unstable-if-unmarked"><code>-Z force-unstable-if-unmarked</code></a></h4>
|
|
<p>Since <code>lib/rustlib/</code> is part of the search path we have to be careful about
|
|
which crates are included in it. In particular, all crates except for the
|
|
standard library are built with the flag <code>-Z force-unstable-if-unmarked</code>, which
|
|
means that you have to use <code>#![feature(rustc_private)]</code> in order to load it (as
|
|
opposed to the standard library, which is always available).</p>
|
|
<p>The <code>-Z force-unstable-if-unmarked</code> flag has a variety of purposes to help
|
|
enforce that the correct crates are marked as <code>unstable</code>. It was introduced
|
|
primarily to allow rustc and the standard library to link to arbitrary crates on
|
|
crates.io which do not themselves use <code>staged_api</code>. <code>rustc</code> also relies on this
|
|
flag to mark all of its crates as <code>unstable</code> with the <code>rustc_private</code> feature so
|
|
that each crate does not need to be carefully marked with <code>unstable</code>.</p>
|
|
<p>This flag is automatically applied to all of <code>rustc</code> and the standard library by
|
|
the bootstrap scripts. This is needed because the compiler and all of its
|
|
dependencies are shipped in <code>sysroot</code> to all users.</p>
|
|
<p>This flag has the following effects:</p>
|
|
<ul>
|
|
<li>Marks the crate as "<code>unstable</code>" with the <code>rustc_private</code> feature if it is not
|
|
itself marked as <code>stable</code> or <code>unstable</code>.</li>
|
|
<li>Allows these crates to access other forced-unstable crates without any need
|
|
for attributes. Normally a crate would need a <code>#![feature(rustc_private)]</code>
|
|
attribute to use other <code>unstable</code> crates. However, that would make it
|
|
impossible for a crate from crates.io to access its own dependencies since
|
|
that crate won't have a <code>feature(rustc_private)</code> attribute, but <em>everything</em>
|
|
is compiled with <code>-Z force-unstable-if-unmarked</code>.</li>
|
|
</ul>
|
|
<p>Code which does not use <code>-Z force-unstable-if-unmarked</code> should include the
|
|
<code>#![feature(rustc_private)]</code> crate attribute to access these forced-unstable
|
|
crates. This is needed for things which link <code>rustc</code> its self, such as <code>MIRI</code> or
|
|
<code>clippy</code>.</p>
|
|
<p>You can find more discussion about sysroots in:</p>
|
|
<ul>
|
|
<li>The <a href="https://github.com/rust-lang/rust/pull/76728">rustdoc PR</a> explaining why it uses <code>extern crate</code> for dependencies loaded
|
|
from <code>sysroot</code></li>
|
|
<li><a href="https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/deps.20in.20sysroot/">Discussions about sysroot on
|
|
Zulip</a></li>
|
|
<li><a href="https://rust-lang.zulipchat.com/#narrow/stream/182449-t-compiler.2Fhelp/topic/How.20to.20create.20an.20executable.20accessing.20.60rustc_private.60.3F">Discussions about building rustdoc out of
|
|
tree</a></li>
|
|
</ul>
|
|
<h2 id="passing-flags-to-commands-invoked-by-bootstrap"><a class="header" href="#passing-flags-to-commands-invoked-by-bootstrap">Passing flags to commands invoked by <code>bootstrap</code></a></h2>
|
|
<p>Conveniently <code>./x</code> allows you to pass stage-specific flags to <code>rustc</code> and
|
|
<code>cargo</code> when bootstrapping. The <code>RUSTFLAGS_BOOTSTRAP</code> environment variable is
|
|
passed as <code>RUSTFLAGS</code> to the bootstrap stage (<code>stage0</code>), and
|
|
<code>RUSTFLAGS_NOT_BOOTSTRAP</code> is passed when building artifacts for later stages.
|
|
<code>RUSTFLAGS</code> will work, but also affects the build of <code>bootstrap</code> itself, so it
|
|
will be rare to want to use it. Finally, <code>MAGIC_EXTRA_RUSTFLAGS</code> bypasses the
|
|
<code>cargo</code> cache to pass flags to rustc without recompiling all dependencies.</p>
|
|
<ul>
|
|
<li><code>RUSTDOCFLAGS</code>, <code>RUSTDOCFLAGS_BOOTSTRAP</code> and <code>RUSTDOCFLAGS_NOT_BOOTSTRAP</code> are
|
|
analogous to <code>RUSTFLAGS</code>, but for <code>rustdoc</code>.</li>
|
|
<li><code>CARGOFLAGS</code> will pass arguments to cargo itself (e.g. <code>--timings</code>).
|
|
<code>CARGOFLAGS_BOOTSTRAP</code> and <code>CARGOFLAGS_NOT_BOOTSTRAP</code> work analogously to
|
|
<code>RUSTFLAGS_BOOTSTRAP</code>.</li>
|
|
<li><code>--test-args</code> will pass arguments through to the test runner. For <code>tests/ui</code>,
|
|
this is <code>compiletest</code>. For unit tests and doc tests this is the <code>libtest</code>
|
|
runner.</li>
|
|
</ul>
|
|
<p>Most test runners accept <code>--help</code>,
|
|
which you can use to find out the options accepted by the runner.</p>
|
|
<h2 id="environment-variables"><a class="header" href="#environment-variables">Environment Variables</a></h2>
|
|
<p>During bootstrapping, there are a bunch of compiler-internal environment
|
|
variables that are used. If you are trying to run an intermediate version of
|
|
<code>rustc</code>, sometimes you may need to set some of these environment variables
|
|
manually. Otherwise, you get an error like the following:</p>
|
|
<pre><code class="language-text">thread 'main' panicked at 'RUSTC_STAGE was not set: NotPresent', library/core/src/result.rs:1165:5
|
|
</code></pre>
|
|
<p>If <code>./stageN/bin/rustc</code> gives an error about environment variables, that usually
|
|
means something is quite wrong -- such as you're trying to compile <code>rustc</code> or
|
|
<code>std</code> or something which depends on environment variables. In the unlikely case
|
|
that you actually need to invoke <code>rustc</code> in such a situation, you can tell the
|
|
bootstrap shim to print all <code>env</code> variables by adding <code>-vvv</code> to your <code>x</code>
|
|
command.</p>
|
|
<p>Finally, bootstrap makes use of the <a href="https://github.com/rust-lang/cc-rs">cc-rs crate</a> which has <a href="https://docs.rs/cc/latest/cc/#external-configuration-via-environment-variables">its own
|
|
method</a> of configuring <code>C</code> compilers and <code>C</code> flags via environment
|
|
variables.</p>
|
|
<h2 id="clarification-of-build-commands-stdout"><a class="header" href="#clarification-of-build-commands-stdout">Clarification of build command's <code>stdout</code></a></h2>
|
|
<p>In this part, we will investigate the build command's <code>stdout</code> in an action
|
|
(similar, but more detailed and complete documentation compare to topic above).
|
|
When you execute <code>x build --dry-run</code> command, the build output will be something
|
|
like the following:</p>
|
|
<pre><code class="language-text">Building stage0 library artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
|
|
Copying stage0 library from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
|
|
Building stage0 compiler artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
|
|
Copying stage0 rustc from stage0 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
|
|
Assembling stage1 compiler (x86_64-unknown-linux-gnu)
|
|
Building stage1 library artifacts (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu)
|
|
Copying stage1 library from stage1 (x86_64-unknown-linux-gnu -> x86_64-unknown-linux-gnu / x86_64-unknown-linux-gnu)
|
|
Building stage1 tool rust-analyzer-proc-macro-srv (x86_64-unknown-linux-gnu)
|
|
Building rustdoc for stage1 (x86_64-unknown-linux-gnu)
|
|
</code></pre>
|
|
<h3 id="building-stage0-stdcompiler-artifacts"><a class="header" href="#building-stage0-stdcompiler-artifacts">Building stage0 {std,compiler} artifacts</a></h3>
|
|
<p>These steps use the provided (downloaded, usually) compiler to compile the local
|
|
Rust source into libraries we can use.</p>
|
|
<h3 id="copying-stage0-stdrustc"><a class="header" href="#copying-stage0-stdrustc">Copying stage0 {std,rustc}</a></h3>
|
|
<p>This copies the library and compiler artifacts from <code>cargo</code> into
|
|
<code>stage0-sysroot/lib/rustlib/{target-triple}/lib</code></p>
|
|
<h3 id="assembling-stage1-compiler"><a class="header" href="#assembling-stage1-compiler">Assembling stage1 compiler</a></h3>
|
|
<p>This copies the libraries we built in "building <code>stage0</code> ... artifacts" into the
|
|
<code>stage1</code> compiler's <code>lib/</code> directory. These are the host libraries that the
|
|
compiler itself uses to run. These aren't actually used by artifacts the new
|
|
compiler generates. This step also copies the <code>rustc</code> and <code>rustdoc</code> binaries we
|
|
generated into <code>build/$HOST/stage/bin</code>.</p>
|
|
<p>The <code>stage1/bin/rustc</code> is a fully functional compiler built with stage0 (precompiled) compiler and std.
|
|
To use a compiler built entirely from source with the in-tree compiler and std, you need to build the
|
|
stage2 compiler, which is compiled using the stage1 (in-tree) compiler and std.</p>
|
|
|
|
</main>
|
|
|
|
<nav class="nav-wrapper" aria-label="Page navigation">
|
|
<!-- Mobile navigation buttons -->
|
|
<a rel="prev" href="../../building/bootstrapping/intro.html" class="mobile-nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|
<i class="fa fa-angle-left"></i>
|
|
</a>
|
|
|
|
<a rel="next prefetch" href="../../building/bootstrapping/how-bootstrap-does-it.html" class="mobile-nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|
<i class="fa fa-angle-right"></i>
|
|
</a>
|
|
|
|
<div style="clear: both"></div>
|
|
</nav>
|
|
</div>
|
|
</div>
|
|
|
|
<nav class="nav-wide-wrapper" aria-label="Page navigation">
|
|
<a rel="prev" href="../../building/bootstrapping/intro.html" class="nav-chapters previous" title="Previous chapter" aria-label="Previous chapter" aria-keyshortcuts="Left">
|
|
<i class="fa fa-angle-left"></i>
|
|
</a>
|
|
|
|
<a rel="next prefetch" href="../../building/bootstrapping/how-bootstrap-does-it.html" class="nav-chapters next" title="Next chapter" aria-label="Next chapter" aria-keyshortcuts="Right">
|
|
<i class="fa fa-angle-right"></i>
|
|
</a>
|
|
</nav>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<script>
|
|
window.playground_copyable = true;
|
|
</script>
|
|
|
|
|
|
<script src="../../elasticlunr.min.js"></script>
|
|
<script src="../../mark.min.js"></script>
|
|
<script src="../../searcher.js"></script>
|
|
|
|
<script src="../../clipboard.min.js"></script>
|
|
<script src="../../highlight.js"></script>
|
|
<script src="../../book.js"></script>
|
|
|
|
<!-- Custom JS scripts -->
|
|
<script src="../../mermaid.min.js"></script>
|
|
<script src="../../mermaid-init.js"></script>
|
|
|
|
|
|
</div>
|
|
</body>
|
|
</html>
|