My Linux Mint/Mate computer runs into problems compiling Blake2 and Blake3 crates. With the source code exactly as per the demo given the crates, (fn main(){wrapper added), with Blake3
version 0.3.5 I get:-
Updating crates.io index
Compiling typenum v1.12.0
Compiling cc v1.0.58
Compiling subtle v1.0.0
Compiling arrayvec v0.5.1
error[E0658]: use of unstable library feature 'maybe_uninit' (see issue #53491)
--> /home/richard/.cargo/registry/src/github.com-1ecc6299db9ec823/arrayvec-0.5.1/src/maybe_uninit.rs:4:5
|
4 | use std::mem::MaybeUninit as StdMaybeUninit;
| ^^^^^^^^^^^^^^^^^^^^^
Followed by 4 more errors all similarly related. Going back to Blake2 version 0.9.0 1 get tens of such messages. Version 0.8.1 does compile, but then will not run the sample code 'No methods named update or finalize'.
As a mere user of the crates, (I do intend to alter official crates) and not really understand the issue, how do I implement Blake 3 on my computer? Thanks in advance.
The compile error for Blake3 is because you are using an old version of the compiler. If you installed rust from the package manager, I recommend uninstalling that version (both cargo and rustc). The recommended way to install it is to follow the instructions at [https://rustup.rs](https://rustup.rs). If you already have installed it that way, you can run rustup update to get the latest version.
Thanks. I imagined asking my IDE to update everything it would have done to all that. However,
what I got after updating rust by hand took me back to the days when 'C' drove me mad and I gave up using it. ('blake3 = "0.3.5"' is the only cargo dependency):-
/home/richard/.cargo/bin/cargo build --color=always
Updating crates.io index
Blocking waiting for file lock on package cache (3 times)
Compiling typenum v1.12.0
Compiling version_check v0.9.2
Compiling cc v1.0.58
Compiling subtle v2.2.3
Compiling arrayvec v0.5.1
Compiling constant_time_eq v0.1.5
Compiling cfg-if v0.1.10
Compiling arrayref v0.3.6
Compiling generic-array v0.14.3
Compiling blake3 v0.3.5
The following warnings were emitted during compilation:
warning: The C compiler "cc" does not support -mavx512f and -mavx512vl.
warning: c/blake3_sse41_x86-64_unix.S:1:58: error: missing binary operator before token "("
warning: #if defined(ELF) && defined(CET) && __has_include(<cet.h>)
warning: ^
error: failed to run custom build command for blake3 v0.3.5
(beginning of a 90 line error message ending with build failed, exit code 101.)
I thought rust crates were universally written in rust! The Blake algorithm invoked may be complex, but invoke an algorithm is all the crate does. I have no idea it needs so much support. (This concept enters my head with many crates.) Where would it have got cc v1.0.58 from? The one in my computer is 4.8.4.
My workaround is to use blake3 version 0.2.3, with which I am having success. (0.3.* always seems to invoke 0.3.5, another unexpected odd effect). I learn more about rust every day! My new question:- What is wrong that I am now getting this? Will I be unable to update the blake3, ever? I simply do not understand the implications of what is going on.
The cc v1.0.58 is a Rust crate used in build scripts to compile code using the system cc, your 4.8.4. From your error message, this is being used to compile blake3_sse41_x86-64_unix.S, an assembly file, so it seems the blake3 crate is not written in pure, portable Rust. However, it looks like they have a "pure" feature to opt out of that.
[dependencies]
blake3 = { version = "0.3.5", features = ["pure"] }
Note that blake3 is using cc to build its assembly code because the stable Rust compiler doesn't support assembly yet. However, RFC 2873 was officially accepted just last week—a major step toward adding this feature to stable Rust. In the future, blake3 will be able to build its optimized assembly without using a C compiler.
Apologies for the trouble here. The __has_include(<cet.h>) issue you were seeing is a build break that affected systems with older C compilers, like your GCC 4.8.4. The break was introduced a few weeks ago in in version 0.3.5 of the blake3 crate. We released version 0.3.6 a couple days ago with a fix. Hopefully if you try again today it will work.
Note that the blake3 crate doesn't assume that you have a C compiler, or that your C compiler is particularly new. It checks for compiler support and automatically disables features that can't build. (This is the source of the "cc" does not support -mavx512f and -mavx512vl warning you included above.) However, we don't automatically recover from unexpected build failures like this one, because we don't want build bugs to silently accumulate over time.
Yes for that reason, and also because AVX-512 SIMD intrinsics aren't available in stable Rust. I'm really looking forward to trying Rust inline assembly when that's ready.
This is a fair question BLAKE3 is indeed a bit more complicated than other hash functions, but not dramatically so, at least not until you start doing fancy optimizations. The biggest source of complexity in the blake3 crate is that it provides optimized implementations for many different types of processors. In particular, BLAKE3 is designed to take advantage of something called SIMD ("same instruction multiple data") instructions. Intel has released many different flavors of these instructions over the years, and the blake3 crate targets several of them and then does runtime CPU feature checks to pick the fastest implementation it can.
If you want to see what BLAKE3 looks like without any SIMD optimizations (and without multithreading, another big source of complexity), you can take a look at the reference implementation here. It's a few hundred lines of no_std-compatible Rust.
BLAKE3 is indeed a bit more complicated than other hash functions, but not dramatically so, at least not until you start doing fancy optimizations. The biggest source of complexity in the