Release build does not work on aarch64 (M1)

[curtisy1]

First off, great project.

I've been trying to build swww on my M1 Mac running Asahi Linux today but it fails with the following error message in release

Both operands to a binary operator are not of the same type!
  %7198 = xor i64 %7197, i32 4
in function _ZN5image2io14free_functions12load_decoder17h972a54ccb2943d7eE
LLVM ERROR: Broken function found, compilation aborted!

error: could not compile `swww`

Caused by:
  process didn't exit successfully: `rustc --crate-name swww --edition=2021 src/main.rs --error-format=json --json=diagnostic-rendered-ansi,artifacts,future-incompat --crate-type bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C codegen-units=1 -C debuginfo=0 -C metadata=313bff2c136129f8 -C extra-filename=-313bff2c136129f8 --out-dir /home/curtisy/swww/target/release/deps -C strip=symbols -L dependency=/home/curtisy/swww/target/release/deps --extern bincode=/home/curtisy/swww/target/release/deps/libbincode-3471bfd3a21c41ad.rlib --extern clap=/home/curtisy/swww/target/release/deps/libclap-b0083cad16eb3bb1.rlib --extern fast_image_resize=/home/curtisy/swww/target/release/deps/libfast_image_resize-6ffcf43ef1ad24bd.rlib --extern fork=/home/curtisy/swww/target/release/deps/libfork-a88127e95e4d0aac.rlib --extern image=/home/curtisy/swww/target/release/deps/libimage-1be0f6cd5a85dbe3.rlib --extern keyframe=/home/curtisy/swww/target/release/deps/libkeyframe-fa0b216abfb58feb.rlib --extern lazy_static=/home/curtisy/swww/target/release/deps/liblazy_static-3be040a087e9797f.rlib --extern log=/home/curtisy/swww/target/release/deps/liblog-48f21aabe46af05d.rlib --extern lzzzz=/home/curtisy/swww/target/release/deps/liblzzzz-bb8df0835a92e3a7.rlib --extern rand=/home/curtisy/swww/target/release/deps/librand-00b8660841df70ef.rlib --extern serde=/home/curtisy/swww/target/release/deps/libserde-bec4c4a54a6d005a.rlib --extern simplelog=/home/curtisy/swww/target/release/deps/libsimplelog-da9c39d74fa6aed7.rlib --extern smithay_client_toolkit=/home/curtisy/swww/target/release/deps/libsmithay_client_toolkit-1bbbebdc277ae777.rlib -L native=/home/curtisy/swww/target/release/build/lzzzz-ee97ccfbf62b1f56/out -L native=/usr/lib` (exit status: 101)
cargo build --release --verbose  20,552 user 0,091 system 99% cpu (20,677 wasted time).

When I disable lto in Cargo.toml, it seems to be working fine, so it's not a huge issue. Would be great if it worked out of the box though, so I could use the AUR.

If there's anything I can do to help troubleshoot, please let me know.

[LGFae]

Hm. I wonder whether we should report this to the image crate guys. Or even if we should go all the way up to the rust team themselves. In any case, can you confirm if it still happens with just lto= "thin"?

[folliehiyuki]

I'm hitting the same error on AlpineLinux CI: https://gitlab.alpinelinux.org/alpine/aports/-/merge_requests/41971.

The error only appears in aarch64. The build for the other platforms pass.

[LGFae]

@folliehiyuki can you by any chance manually edit Cargo.toml and delete the line lto = true? Just to confirm if that is indeed also the issue with you.

[folliehiyuki]

You can check the build template here: https://git.alpinelinux.org/aports/tree/testing/swww/APKBUILD.

I don't do anything special there though. lto=true is enforced via environment variable I think.

[nekopsykose]

I don't do anything special there though. lto=true is enforced via environment variable I think.

you can export CARGO_PROFILE_RELEASE_LTO= to set it between true/thin/0(?) to test each one

[LGFae]

The image crate guys pointed out that this seems to be this error, in rustc. Which in turn seems to be an error in llvm. They were both patched already, so this should be automatically fixed for us when rustc 1.66.0 comes out (which should be in January, if I am not mistaken).

[curtisy1]

Sorry for the late reply and thanks for the help and update on this. I just tried again use lto = "thin" which is also working fine. Since there's a fix available in a month, I think this can be closed for now. Unless you want to keep it open for tracking @Horus645 ?

[LGFae]

Yeah, I'd rather have it open for now, specially since the Alpine build is failing. I just want to make sure it truly is fixed a month from now.

---

Edit: I just realized this issue can also work as a sort of warning and help page for any other aarch64 users having the same problem. So yeah, let's keep it here.

[LGFae]

A new rust version is out! Can anyone with an M1 confirm whether this has been fixed?

[curtisy1]

Just tested compiling in release mode using the latest 1.67.0 version of rust.

Can confirm it now works fine and compiles without any errors