- Timestamp:
- 01/24/2019 07:09:29 PM (5 years ago)
- Branches:
- 10.0, 10.1, 11.0, 11.1, 11.2, 11.3, 12.0, 12.1, 8.4, 9.0, 9.1, bdubbs/svn, kea, ken/TL2024, ken/inkscape-core-mods, ken/tuningfonts, lazarus, lxqt, plabs/newcss, plabs/python-mods, python3.11, qt5new, rahul/power-profiles-daemon, renodr/vulkan-addition, trunk, upgradedb, xry111/intltool, xry111/llvm18, xry111/soup3, xry111/test-20220226, xry111/xf86-video-removal
- Children:
- 62f58c7a, 8862f42
- Parents:
- c4d96918
- File:
-
- 1 edited
Legend:
- Unmodified
- Added
- Removed
-
general/prog/rust.xml
rc4d96918 r25997c4a 7 7 <!ENTITY rust-download-http "https://static.rust-lang.org/dist/rustc-&rust-version;-src.tar.gz"> 8 8 <!ENTITY rust-download-ftp " "> 9 <!ENTITY rust-md5sum "6790c24fe5e8fb5a5f7efbfbcc6fea65"> 10 <!ENTITY rust-size "101 MB"> 11 <!ENTITY rust-buildsize "6.5 GB (679 MB installed) including 270MB of ~/.cargo files for the user building this (add 1.4GB if running the tests)"> 12 <!ENTITY rust-time "27 SBU (add 13 SBU for tests, both with 4 processors)"> 9 <!ENTITY rust-md5sum "366f049777e00d0d6f15d25895485efb"> 10 <!ENTITY rust-size "152 MB"> 11 <!-- Gentle Reminder: buildsize is how much the user requires for the real 12 install, i.e. the source with its DESTDIR *plus* the DESTDIR. You 13 can 'mkdir /tmp/RUST ; cp -a install/* /tmp/RUST' and then run 'du -sch' 14 to measure it. --> 15 16 <!ENTITY rust-buildsize "6.2 GB (475 MB installed) including 295MB of ~/.cargo files for the user building this. Add 1.5GB if installing the documentation (an extra 314MB is installed), and 2.0GB if running the tests"> 17 <!ENTITY rust-time "34 SBU (add 3 SBU if installing the documentation and 15 SBU for tests, both with 4 processors)"> 13 18 ]> 14 19 … … 33 38 The <application>Rust</application> programming language is designed 34 39 to be a safe, concurrent, practical language. 40 </para> 41 42 <para> 43 This package is updated on a six-weekly release cycle. Because it is 44 such a large and slow package to build, and is at the moment only required 45 by five packages in this book, the BLFS editors take the view that it 46 should only be updated when that is necessary (either to fix problems, 47 or to allow a new version of <application>firefox</application> to build). 35 48 </para> 36 49 … … 42 55 connection. 43 56 </para> 57 58 <para> 59 These crates will then remain in various forms (cache, directories of 60 extracted source), in <filename class="directory">~/.cargo</filename> for 61 ever more. It is common for large <application>rust</application> packages 62 to use multiple versions of some crates. If you purge the files before 63 updating this package, very few crates will need to be updated by the 64 packages in this book which use it (and they will be downloaded as 65 required). But if you retain an older version as a fallback option and 66 then use it (that would require <emphasis>not</emphasis> building in 67 <filename class="directory">/usr</filename>), it is likely that it will 68 then have to re download some crates. For a full download (i.e. starting 69 with an empty or missing <filename class="directory">~/.cargo</filename>) 70 downloading the external cargo files for this version only takes a minute 71 or so on a fast network. 72 </para> 73 74 <note> 75 <para> 76 When you upgrade to a newer version, the new libraries will have various 77 hashes in their names and therefore there will be a mix of versions but 78 only one of each will be usable. A binary distribution would use its 79 package manager to delete all the old <application>rust</application> 80 installation before updating. You may wish to do the same to save space. 81 </para> 82 </note> 44 83 45 84 <para> … … 63 102 </para> 64 103 <para> 65 Repeated builds of this package on the same machine show a wide range 66 of build times. Some of this might be due to variations in downloading 67 the required cargo files if they are not already present, but this does 68 not seem to adequately explain the variations. 104 Unlike with previous versions, the build times of this version when 105 repeated on the same machine seem reasonably consistent. 69 106 </para> 70 107 <para> … … 123 160 </para> 124 161 162 <!-- comment out while using shipped LLVM 125 163 <bridgehead renderas="sect4">Recommended</bridgehead> 126 164 <para role="recommended"> 127 165 <package>clang</package> from <xref linkend="llvm"/> 128 166 (built with -DLLVM_LINK_LLVM_DYLIB=ON) 129 </para> 167 </para>--> 130 168 131 169 <bridgehead renderas="sect4">Optional</bridgehead> 132 170 <para role="optional"> 133 <xref linkend="gdb"/> ( recommended if running the testsuite)171 <xref linkend="gdb"/> (used by the testsuite if it is present) 134 172 </para> 135 173 … … 142 180 <title>Installation of Rust</title> 143 181 144 <note> 145 <para> 146 This package is updated on a six-weekly release cycle. Because it is 147 such a large and slow package to build, and is at the moment only required 148 by five packages in this book, the BLFS editors take the view that it 149 should only be updated when that is necessary. 150 </para> 151 </note> 152 153 <para> 154 First create a suitable <filename>config.toml</filename> file 155 which will configure the build : 182 <para> 183 First create a suitable <filename>config.toml</filename> file which will 184 configure the build. Unlike with previous releases, where even quite old 185 system versions of <application>LLVM</application>worked well, this 186 version ships with a development version and using the current <xref 187 linkend="llvm"/> release is known to result in breakage in some 188 circumstances. 156 189 </para> 157 190 … … 159 192 # see config.toml.example for more possible options 160 193 [llvm] 194 195 # use ninja 196 ninja = true 197 161 198 targets = "X86" 162 163 # When using system llvm prefer shared libraries164 link-shared = true 199 # When compiling LLVM, the experimental targets (WebAssembly 200 # and RISCV) are built by default - omit them 201 experimental-targets = "" 165 202 166 203 [build] 204 # omiti HTML docs to save time and space (comment this to build them) 205 docs = false 206 167 207 # install cargo as well as rust 168 208 extended = true … … 170 210 [install] 171 211 prefix = "/usr" 212 # docdir is used even if the full awesome docs are not installed 172 213 docdir = "share/doc/rustc-&rust-version;" 173 214 … … 180 221 codegen-tests = false 181 222 182 [target.x86_64-unknown-linux-gnu] 183 # delete this *section* if you are not using system llvm. 184 # NB the output of llvm-config (i.e. help options) may be 185 # dumped to the screen when config.toml is parsed. 186 llvm-config = "/usr/bin/llvm-config" 223 # get a trace if there is an Internal Compiler Exception 224 backtrace-on-ice = true 187 225 188 226 EOF</userinput></screen> … … 194 232 195 233 <screen><userinput>export RUSTFLAGS="$RUSTFLAGS -C link-args=-lffi" && 196 ./x.py build</userinput></screen> 197 198 <para> 199 The build will report it failed to compile <filename>miri</filename> 200 because of multiple potential crates for `log`, but that should be followed 201 by a message that the build completed successfully. 202 </para> 234 ./x.py build --exclude src/tools/miri</userinput></screen> 203 235 204 236 <note> … … 208 240 <phrase revision="systemd">systemd journal</phrase> 209 241 for traps on invalid opcodes, and for segmentation faults. 210 In themselves these are nothing to worry about, although if the 211 output from the testsuite reports tests which FAIL with such faults 212 then there may be a problem. 242 In themselves these are nothing to worry about, just a way for the 243 test to be terminated. But if the output from the testsuite reports tests 244 which FAIL with segmentation faults (signal 11) then there may be a 245 problem. 213 246 </para> 214 247 </note> … … 217 250 To run the tests issue 218 251 <command>./x.py test --verbose --no-fail-fast | tee rustc-testlog</command>: 219 as with the build, that will use all available CPUs. This runs many suites 220 of tests (in an apparently random order), several will fail in BLFS: 221 compile-fail/issue-37131.rs require a thumbv6m-none-eabi compiler but the 222 BLFS build does not cater for 223 that, ui/issue-49851/compiler-builtins-error.rs and ui/issue-50993.rs (both 224 run twice) require a thumbv7em-none-eabihf compiler, and seven tests in 225 debuginfo-gdb will fail because gdb-8.1 changed the output format. If 226 <application>gdb</application> has not been installed, most of the gdb tests 227 will fail. 228 </para> 229 230 <para> 231 If you wish to look at the numbers for the results, you can find the total 232 number of tests which were considered by running: 252 as with the build, that will use all available CPUs. 253 </para> 254 255 <para> 256 The instructions above do not build ARM compilers, so the testsuite 257 <emphasis>will</emphasis> fail and the tests will be reported to end in 258 error, with a backtrace of the last failing test. On a good run, 3 tests 259 which need Thumb (ARM) compilers will fail, all in <filename 260 class="directory">ui/issues</filename> for issues 37131, 49851 and 50993. 261 Occasionally a fourth test, in run-make, 'sysroot-crates-are-unstable', 262 has been known to fail. That is probably harmless. As with all large 263 testsuites, other tests might fail on some machines - if the number of 264 failures is in the single digits, check the log for 'FAILED' and review 265 lines above that. Any mention of SIGSEGV or signal 11 in a failing test 266 is a cause for concern. 267 </para> 268 269 <para> 270 Therefore, you should determine the number of tests, failures, etc. The 271 total number of tests which were considered is found by running: 233 272 </para> 234 273 … … 236 275 237 276 <para> 238 That should report 1 7101tests. Similarly, the total tests which failed can277 That should report 15795 tests. Similarly, the total tests which failed can 239 278 be found by running: 240 279 </para> … … 245 284 And similarly for the tests which passed use $4, for those which were ignored 246 285 (i.e. skipped) use $8 (and $10 for 'measured', $12 for 'filtered out' but both 247 are probably zero). The breakdown does not match the overall total.286 are probably zero). The breakdown does not quite match the overall total. 248 287 </para> 249 288 … … 294 333 </para> 295 334 335 <!-- comment while using shipped LLVM 296 336 <para> 297 337 <command>[target.x86_64-unknown-linux-gnu]</command>: the syntax of … … 302 342 against the shipped llvm, or do not have clang, but the resulting build will 303 343 be larger and take longer. 304 </para> 344 </para>--> 305 345 306 346 <para> … … 309 349 to the build. On some systems, linking fails to include libffi unless 310 350 this is used. The reason why this is needed is not clear. 351 </para> 352 353 <para> 354 <command>--exclude src/tools/miri</command>: For a long time, the miri 355 crate (an interpreter for the Midlevel Intermediate Representation) 356 has failed to build on releases. It is optional, but the failure 357 messages can persuade people that the whole build failed. 311 358 </para> 312 359
Note:
See TracChangeset
for help on using the changeset viewer.