Build s390x-unknown-linux-musl target

[messense]

bors: amd64 --target s390x-unknown-linux-musl

[messense]

bors try amd64 --target s390x-unknown-linux-musl

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

  = note: /usr/local/musl/bin/../lib/gcc/s390x-unknown-linux-musl/9.2.0/../../../../s390x-unknown-linux-musl/bin/ld: /home/rust/src/target/s390x-unknown-linux-musl/debug/deps/libopenssl_sys-70172c64409e3e90.rlib(curve448.o): in function `recode_wnaf':
          /home/rust/src/target/s390x-unknown-linux-musl/debug/build/openssl-sys-1de3ca3326f5bf22/out/openssl-build/build/src/crypto/ec/curve448/curve448.c:575: undefined reference to `__ctzdi2'
          /usr/local/musl/bin/../lib/gcc/s390x-unknown-linux-musl/9.2.0/../../../../s390x-unknown-linux-musl/bin/ld: read-only segment has dynamic relocations
          collect2: error: ld returned 1 exit status

Hmm, not sure what's going on.

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors try arm64 armv7 --target s390x-unknown-linux-musl

[messense]

bors r+

[bors[bot]]

Build failed:

• conclusion

[messense]

bors r+

[bors[bot]]

Build failed:

• conclusion

[messense]

bors try arm64 --target s390x-unknown-linux-musl

[paulwratt]

Hmm, not sure what's going on.

I would check for an s390 patch for OpenSSL, or maybe if there is a version requirement (either for Rust or s390)

[messense]

__ctzdi2 comes from compiler-builtins, we're building a custom Rust std for s390x musl here since there is none from official release, probably need to check whether compiler-builtins was built properly.

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors try armv7 --target s390x-unknown-linux-musl

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors r+

[bors[bot]]

Build failed:

• conclusion

[messense]

bors try amd64 --target s390x-unknown-linux-musl

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors retry

[bors[bot]]

try

Build failed:

• conclusion

[messense]

bors try armv7 --target s390x-unknown-linux-musl

[messense]

bors r+

[bors[bot]]

try

Already running a review

[bors[bot]]

try

Build succeeded:

• conclusion

[bors[bot]]

Build succeeded:

• conclusion

[paulwratt]

I just checked that last conclusion, in the build script (step 2 of 3) the build docker sub-step has this at line 120. is it normal?

#0 0.093 fatal: Not a valid object name af0c8329a3c6a17b5f2f0730899b9ecba2cf69ff^{commit}

https://github.com/messense/rust-musl-cross/actions/runs/3087155053/jobs/4992234259#step:8:122

---

There seems to be an issue that generates warnings in the GCC package starting here:

https://github.com/messense/rust-musl-cross/actions/runs/3087155053/jobs/4992234259#step:8:353

EDIT: seems to be various linux.h doing so for each *.c file that includes ./tm.h - In fact that appears to be the only reason the log file is sooooo huuuuuge, as something then re-dumps those in a different format, starting here

https://github.com/messense/rust-musl-cross/actions/runs/3087155053/jobs/4992234259#step:8:822

[messense]

I just checked that last conclusion, in the build script (step 2 of 3) the build docker sub-step has this at line 120. is it normal?

https://stackoverflow.com/a/72091309

Trying it out in https://github.com/messense/rust-musl-cross/commit/e57aa6581b6e3913bddc870c4ecca3fb360e566e

[paulwratt]

ok, and I just checked which commit it was (and presumed rightly) it was the (last?) br-bot (bors) commit

[paulwratt]

also it seems someone invented "string format police" (the other reason the log is so long).

is there any way to get rid on -Wformat-diag before you compile

it sounds like those header warnings are because there is not #include once or #pragma once in there somewhere

( I realize these are GCC build issues, might not even be part of the musl-cross-make )

EDIT I just posted on musl-cross-make so the warnings might disappear - that should result in a slight speed up too - it depends tho, because any fixes on their end wont affect that 0.9.9 archive (which I see you just updated to current)