| <!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 --> |
| <link rel="stylesheet" href="../../pagetoc.css"> |
| |
| |
| <!-- Provide site root and default themes to javascript --> |
| <script> |
| const path_to_root = "../../"; |
| const default_light_theme = "light"; |
| const default_dark_theme = "navy"; |
| window.path_to_searchindex_js = "../../searchindex.js"; |
| </script> |
| <!-- Start loading toc.js asap --> |
| <script src="../../toc.js"></script> |
| </head> |
| <body> |
| <div id="mdbook-help-container"> |
| <div id="mdbook-help-popup"> |
| <h2 class="mdbook-help-title">Keyboard shortcuts</h2> |
| <div> |
| <p>Press <kbd>←</kbd> or <kbd>→</kbd> to navigate between chapters</p> |
| <p>Press <kbd>S</kbd> or <kbd>/</kbd> to search in the book</p> |
| <p>Press <kbd>?</kbd> to show this help</p> |
| <p>Press <kbd>Esc</kbd> to hide this help</p> |
| </div> |
| </div> |
| </div> |
| <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 = false; |
| } |
| if (sidebar === 'visible') { |
| sidebar_toggle.checked = true; |
| } else { |
| html.classList.remove('sidebar-visible'); |
| } |
| </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 (`/`)" 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" rel="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"> |
| <div class="search-wrapper"> |
| <input type="search" id="searchbar" name="searchbar" placeholder="Search this book ..." aria-controls="searchresults-outer" aria-describedby="searchresults-header"> |
| <div class="spinner-wrapper"> |
| <i class="fa fa-spinner fa-spin"></i> |
| </div> |
| </div> |
| </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> |
| <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 and standard library</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 1</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 besides 0, 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> |
| <script src="../../pagetoc.js"></script> |
| |
| |
| |
| </div> |
| </body> |
| </html> |
