0.6.0 fail to compile uu_stty (lib) on ppc64le

[omnivagant]

warning: use of deprecated type alias `uucore::libc::time_t`: This type is changed to 64-bit in musl 1.2.0, we'll follow that change in the future release. See #1848 for more info.
  --> src/uu/uptime/src/uptime.rs:15:19
   |
15 | use uucore::libc::time_t;
   |                   ^^^^^^
   |
   = note: `#[warn(deprecated)]` on by default

warning: use of deprecated type alias `uucore::libc::time_t`: This type is changed to 64-bit in musl 1.2.0, we'll follow that change in the future release. See #1848 for more info.
   --> src/uu/uptime/src/uptime.rs:236:54
    |
236 | fn process_utmpx(file: Option<&OsString>) -> (Option<time_t>, usize) {
    |                                                      ^^^^^^

warning: use of deprecated type alias `uucore::libc::time_t`: This type is changed to 64-bit in musl 1.2.0, we'll follow that change in the future release. See #1848 for more info.
   --> src/uu/uptime/src/uptime.rs:251:61
    |
251 |                     boot_time = Some(dt.unix_timestamp() as time_t);
    |                                                             ^^^^^^

warning: use of deprecated type alias `uucore::libc::time_t`: This type is changed to 64-bit in musl 1.2.0, we'll follow that change in the future release. See #1848 for more info.
   --> src/uu/uptime/src/uptime.rs:278:35
    |
278 | fn print_uptime(boot_time: Option<time_t>) -> UResult<()> {
    |                                   ^^^^^^

error[E0432]: unresolved imports `nix::libc::TCGETS2`, `nix::libc::termios2`
  --> src/uu/stty/src/stty.rs:25:17
   |
25 | use nix::libc::{TCGETS2, termios2};
   |                 ^^^^^^^  ^^^^^^^^ no `termios2` in the root
   |                 |
   |                 no `TCGETS2` in the root
   |
help: a similar name exists in the module
   |
25 - use nix::libc::{TCGETS2, termios2};
25 + use nix::libc::{TCGETS, termios2};
   |
help: a similar name exists in the module
   |
25 - use nix::libc::{TCGETS2, termios2};
25 + use nix::libc::{TCGETS2, termios};
   |

   Compiling uu_sha1sum v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/sha1sum)
   Compiling uu_sha512sum v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/sha512sum)
   Compiling uu_sha256sum v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/sha256sum)
   Compiling uu_cksum v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/cksum)
   Compiling uu_sha224sum v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/sha224sum)
   Compiling uu_sha384sum v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/sha384sum)
   Compiling uu_b2sum v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/b2sum)
   Compiling uu_md5sum v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/md5sum)
   Compiling uu_base64 v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/base64)
   Compiling uu_basenc v0.6.0 (/builds/alpine/aports/community/uutils/src/coreutils-0.6.0/src/uu/basenc)
For more information about this error, try `rustc --explain E0432`.
error: could not compile `uu_stty` (lib) due to 1 previous error
warning: build failed, waiting for other jobs to finish...
warning: `uu_uptime` (lib) generated 4 warnings
warning: `uucore` (lib) generated 4 warnings

[oech3]

Does Linux on ppc64le support arbital baudrate?

[omnivagant]

unsure, haven't dug too far but found this https://www.openwall.com/lists/musl/2024/04/11/5

I'll revert #10526 for that architecture for now

[oech3]

You can send a PR to fix cfg block for ppc64le (after some clippy eoors was fixed).

[omnivagant]

perhaps it can be called some other way on PowerPC?

https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/uapi/asm/termios.h
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/arch/powerpc/include/uapi/asm/ioctls.h

[oech3]

Even it is correct, I can't test it and this repo cannot add CI for ppc64le.

[sandeepgupta12]

We’re currently working on enabling CI/CD coverage for ppc64le (Linux on Power) in a downstream fork, and we’re encountering the same build failure in uu_stty related to nix::libc::{TCGETS2, termios2}.

This reproduces consistently during cargo build on ppc64le and matches the behavior described in this issue.

For reference, here is a public CI job from our fork showing the failure:
https://github.com/PankhudiJ17/coreutils/actions/runs/21705930197/job/62597393830

We’re in the process of finalizing our CI setup for ppc64le and will follow up with any findings or a minimal, compile-time-gated fix that does not affect existing CI-covered architectures.

I noticed PR #10526 referenced earlier in the discussion. Is that PR (or its general approach, e.g. compile-time gating or falling back from termios2) still considered the preferred direction for addressing this issue?

We’re happy to align with the intended approach while validating it on ppc64le in downstream CI.

[oech3]

yes. I think cfg ppc64le to cfgetospeed is the best effort currently.

[oech3]

Does target_arch = "powerpc64" cover le too?

[sandeepgupta12]

Hey @oech3, using target_arch = "powerpc64" looks fine — we’ve tested the changes on Power machines and they behave as expected.

To fully address the ppc64 build issue, the same exclusion needs to be applied in a couple of additional places as well:

Import of TCGETS2 / termios2
https://github.com/oech3/coreutils/blob/d804b7e86a471e19de4bda0157a3a173e0531c95/src/uu/stty/src/stty.rs#L24

The speed-printing cfg block
https://github.com/oech3/coreutils/blob/d804b7e86a471e19de4bda0157a3a173e0531c95/src/uu/stty/src/stty.rs#L641

Applying the same cfg there should keep behavior unchanged on existing platforms while allowing the code to build cleanly on Power.

[oech3]

clippy disallowed. Please open a PR by yourself.

[sandeepgupta12]

Sure, understood. I’ll open a PR with the required cfg updates at the mentioned locations and follow up there.

[cakebaker]

Closing this issue as it should be fixed by #11050