Skip to content

stty: Updating libc crate is blocked: 0.2.178->0.2.179 #9875

Closed

Description

@oech3

See comments at #8722 .
This blocks adding CI for cygwin to this repo in the future.

It would block pulling fix for #8474 from upstream.

Activity

  1. tgross35 commented on Jan 3, 2026

    @tgross35

    Do you know what exactly changed here? Or would it be possible to attach a debugger and see which call is failing?

    rust-lang/libc#4694 updated readdir_r, and there are a few defs that would have changed from the 11->12 baseline change https://github.com/search?q=repo%3Arust-lang%2Flibc+%2F%5Cbfreebsd1%5B12%5D%5Cb%2F+path%3A%2F%5Esrc%2F&type=code / rust-lang/libc#2406. None of that jumps out to me as obvious, though. @asomers may have a better idea.

  2. oech3 commented on Jan 3, 2026

    @oech3
    ContributorAuthor

    Myself does not have FBSD, but the log https://github.com/uutils/coreutils/suites/53178265891/logs?attempt=1 exists.

    @cakebaker When will the log expired? Would you re-run the CI? (@tgross35 is upstream of libc crate)

  3. tgross35 commented on Jan 3, 2026

    @tgross35

    Fyi if you ever need a FreeBSD, OpenBSD, Solaris, etc machine or Linux on some less common arches, https://portal.cfarm.net/machines/list/ is a reasonably reliable way to do that. AUIU anyone working on a reasonably large open source project can request an account.

    I just checked and cfarm240 (arm64 FreeBSD15) is up and running. Looks like it's cheri-enabled which is unusual, but that might still be fine to reproduce the failure.

  4. asomers commented on Jan 3, 2026

    @asomers

    As @tgross35 mentioned, the libc upgrade you made included switching from the FreeBSD 11+ ABI to FreeBSD 12+. That's a big difference, because it incluces 64-bit inodes. It also increases the size of struct statfs. That's a syscall that your df is probably using. I suggest looking there.

  5. oech3 commented on Jan 4, 2026

    @oech3
    Author
  6. oech3 commented on Jan 4, 2026

    @oech3
    ContributorAuthor

    Any non-backword compat change about time for musl-i686 target at 0.2.178->0.2.179? I saw many undefined at

    fn atime(&self) -> i64 {
    #[cfg(target_pointer_width = "32")]
    {
    self.stat.st_atime.into()
    }
    #[cfg(not(target_pointer_width = "32"))]
    {
    self.stat.st_atime
    }
    }
    fn atime_nsec(&self) -> i64 {
    #[cfg(target_pointer_width = "32")]
    {
    self.stat.st_atime_nsec.into()
    }
    #[cfg(not(target_pointer_width = "32"))]
    {
    self.stat.st_atime_nsec
    }
    }
    fn mtime(&self) -> i64 {
    #[cfg(target_pointer_width = "32")]
    {
    self.stat.st_mtime.into()
    }
    #[cfg(not(target_pointer_width = "32"))]
    {
    self.stat.st_mtime
    }
    }
    fn mtime_nsec(&self) -> i64 {
    #[cfg(target_pointer_width = "32")]
    {
    self.stat.st_mtime_nsec.into()
    }
    #[cfg(not(target_pointer_width = "32"))]
    {
    self.stat.st_mtime_nsec
    }
    }
    fn ctime(&self) -> i64 {
    #[cfg(target_pointer_width = "32")]
    {
    self.stat.st_ctime.into()
    }
    #[cfg(not(target_pointer_width = "32"))]
    {
    self.stat.st_ctime
    }
    }
    fn ctime_nsec(&self) -> i64 {
    #[cfg(target_pointer_width = "32")]
    {
    self.stat.st_ctime_nsec.into()
    }
    #[cfg(not(target_pointer_width = "32"))]
    {
    self.stat.st_ctime_nsec
    }
    }

  7. changed the title [-]df, FreeBSD: Updating libc crate is blocked[/-] [+]Updating libc crate is blocked: 0.2.178->0.2.179[/+] on Jan 4, 2026
  8. asomers commented on Jan 4, 2026

    @asomers

    coreutils/src/uucore/src/lib/features/fsext.rs

    Lines 449 to 454 in 81ee8d1
    // Rust on FreeBSD uses 11.x ABI for filesystem metadata syscalls.
    // Call the right version of the symbol for getmntinfo() result to
    // match libc StatFS layout.
    #[cfg(target_os = "freebsd")]
    #[link_name = "getmntinfo@FBSD_1.0"]
    fn get_mount_info(mount_buffer_p: *mut *mut StatFs, flags: c_int) -> c_int;

    I experimentary changed it and running CI.

    If you're using the FreeBSD 12 version of struct statfs from libc, but using getmntinfo@FBSD_1.0, then that would definitely cause a problem. Why does coreutils define its own FFI binding for getmntinfo instead of using the one from libc?

  9. oech3 commented on Jan 4, 2026

    @oech3
    ContributorAuthor

    I don't know. It was added by different people. libc was bumped to 0.2.178 anyway by removing it.
    But I can't bump to 0.2.179 by i686-musl issue.

  10. changed the title [-]Updating libc crate is blocked: 0.2.178->0.2.179[/-] [+]stty: Updating libc crate is blocked: 0.2.178->0.2.179[/+] on Jan 4, 2026
  11. oech3 commented on Jan 4, 2026

    @oech3
    ContributorAuthor
    RUST_LIBC_UNSTABLE_MUSL_V1_2_3=1
    RUST_LIBC_UNSTABLE_GNU_TIME_BITS=64
    

    Is this something able to add to .toml instead of environment val?

    https://github.com/uutils/coreutils/blob/main/.cargo/config.toml This file seems unrecommended.

  12. tgross35 commented on Jan 4, 2026

    @tgross35

    Could you paste the musl errors you’re seeing?

    No toml config for the env vars. I don’t think you’ll want to use them outside of testing, since you should expect them to break in the future when we switch them to a cfg.

  13. oech3 commented on Jan 4, 2026

    @oech3
    ContributorAuthor
  14. tgross35 commented on Jan 5, 2026

    @tgross35

    Looks like that was unintentional breakage from the time_t changes. rust-lang/libc#4913

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions