-Test failures
-=============
+Architecture-specific notes
+===========================
-Starting from version 1.20.0+dfsg1-1 the Debian packages of rustc no longer
-fail their build if any tests fail. In other words, some tests might have
-failed when building this and future versions of the package. This is due to
-lack of maintainer time to investigate failures.
+armhf armel mips mipsel powerpc powerpcspe
+------------------------------------------
-Many previous test failures were reported to upstream and did not receive a
-timely response, suggesting the failures were not important. I was then forced
-to patch out the test to make the build proceed, so several tests were being
-ignored in practise anyway.
+We only ship debuginfo for libstd and not the compiler itself, otherwise builds
+run out of memory on the Debian buildds, with non-obvious and random errors.
-This brings the Debian package in line with the Fedora package which also
-ignores all test failures. (Many other distributions don't run tests at all.)
+See https://github.com/rust-lang/rust/issues/45854 for details.
-If you think that the Debian rustc package is miscompiling your program in a
-way that the upstream distributed compiler doesn't, you may check the test
-failures here:
+If all your armhf build machines have ~8GB memory or more, you can experiment
+with disabling this work-around (i.e. revert to normal) in d/rules.
-https://buildd.debian.org/status/package.php?p=rustc
+wasm32
+------
-If you can identify a relevant test failure, as well as the patches needed to
-fix it (either to rustc or LLVM), this will speed up the processing of any bug
-reports on the Debian side.
+We ship two different wasm32 targets - wasm32-unknown-unknown and wasm32-wasi -
+in the libstd-rust-dev-wasm32-cross package.
-We will also examine these failures ourselves on a best-effort basis and
-attempt to fix the more serious-looking ones.
+wasm32-unknown-unknown is suitable for web stuff, where you typically will need
+to depending on the rust-wasm-bindgen, js-sys, and web-sys crates. Here, calls
+to libstd stuff (such as println!()) will silently do nothing, as defined in
+``src/libstd/sys/wasm/fs.rs`` and explained in upstream #48564.
+wasm32-wasi is suitable for non-web stuff, and is closer to a "normal" target
+where you expect libstd to be available, and for println!() to actually print
+to stdout. If you just want to cross-compile a regular non-wasm library or
+program to wasm for whatever reason, and only want to run it natively and not
+inside a web browser, use this target.
-Shared libraries
-================
+To run the generated wasm, you will need a runtime:
-For now, the shared libraries of Rust are private.
-The rational is the following:
- * Upstream prefers static linking for now
- - https://github.com/rust-lang/rust/issues/10209
- * rust is still under heavy development. As far as we know, there is
- no commitement from upstream to provide a stable ABI for now.
- Until we know more, we cannot take the chance to have Rust-built packages
- failing at each release of the compiler.
- * Static builds are working out of the box just fine
- * However, LD_LIBRARY_PATH has to be updated when -C prefer-dynamic is used
+- https://github.com/bytecodealliance/wasmtime
+- https://github.com/bytecodealliance/lucet
+- https://github.com/wasmerio/wasmer
+- https://nodejs.org/api/wasi.html (sadly Debian's is too old, ATTOW)
- -- Sylvestre Ledru <sylvestre@debian.org>, Fri, 13 Feb 2015 15:08:43 +0100
+The first 3 are actually also all written in Rust, so one day some of them may
+even be packaged for Debian.
Cross-compiling
the previous paragraph. Yes, it's a total mind fuck. :( Table for clarity:
======================================= =============== ========================
-GNU term / Debian envvar Rust ecosystem, Some parts of the rustc
- rustc and cargo and cargo build scripts
+ Rust ecosystem, Some parts of the rustc
+GNU term / Debian envvar rustc and cargo and cargo build scripts
======================================= =============== ========================
build DEB_BUILD_{ARCH,RUST_TYPE} host build
the machine running the build
that they can be installed and tested on Debian porter boxes, before being
uploaded to unstable and distributed to users.
+
+Test failures
+=============
+
+Starting from version 1.20.0+dfsg1-1 the Debian packages of rustc no longer
+fail the overall build if > 0 tests fail. Instead, we allow up to around 5
+tests to fail. In other words, if you're reading this in a binary package,
+between 0 and 5 tests might have failed when building this.
+
+This is due to lack of maintainer time to investigate all failures. Many
+previous test failures were reported to upstream and did not receive a timely
+response, suggesting the failures were not important. I was then forced to
+patch out the test to make the build proceed, so several tests were being
+ignored in practise anyway.
+
+This brings the Debian package in line with the Fedora package which also
+ignores all test failures. (Many other distributions don't run tests at all.)
+
+If you think that the Debian rustc package is miscompiling your program in a
+way that the upstream distributed compiler doesn't, you may check the test
+failures here:
+
+https://buildd.debian.org/status/package.php?p=rustc
+
+If you can identify a relevant test failure, as well as the patches needed to
+fix it (either to rustc or LLVM), this will speed up the processing of any bug
+reports on the Debian side.
+
+We will also examine these failures ourselves on a best-effort basis and
+attempt to fix the more serious-looking ones.
+
+Uncommon architectures
+----------------------
+
+Debian release architectures armel and s390x currently have more test failures,
+being tracked by upstream here:
+
+- https://github.com/rust-lang/rust/issues/52493 armel
+- https://github.com/rust-lang/rust/issues/52491 s390x
+
+Ports architectures
+-------------------
+
+The number of allowed test failures on certain Debian ports architectures
+(currently powerpc, powerpcspe, sparc64, x32) is raised greatly to help unblock
+progress for porters. Of course, as a user this means you may run into more
+bugs than usual; as mentioned above bugs reports and patches are welcome.
+
+
+Shared libraries
+================
+
+For now, the shared libraries of Rust are private.
+The rational is the following:
+ * Upstream prefers static linking for now
+ - https://github.com/rust-lang/rust/issues/10209
+ * rust is still under heavy development. As far as we know, there is
+ no commitement from upstream to provide a stable ABI for now.
+ Until we know more, we cannot take the chance to have Rust-built packages
+ failing at each release of the compiler.
+ * Static builds are working out of the box just fine
+ * However, LD_LIBRARY_PATH has to be updated when -C prefer-dynamic is used
+
+ -- Sylvestre Ledru <sylvestre@debian.org>, Fri, 13 Feb 2015 15:08:43 +0100
projects / rustc.git / blobdiff