You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
stty: Updating libc crate is blocked: 0.2.178->0.2.179 #9875
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.
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.
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?
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.
Activity
tgross35 commentedon Jan 3, 2026
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.oech3 commentedon Jan 3, 2026
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
libccrate)tgross35 commentedon Jan 3, 2026
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.
asomers commentedon Jan 3, 2026
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 yourdfis probably using. I suggest looking there.oech3 commentedon Jan 4, 2026
oech3 commentedon Jan 4, 2026
Any non-backword compat change about time for musl-i686 target at 0.2.178->0.2.179? I saw many undefined at
coreutils/src/uucore/src/lib/features/safe_traversal.rs
Lines 471 to 535 in 8cf88cd
[-]df, FreeBSD: Updating libc crate is blocked[/-][+]Updating libc crate is blocked: 0.2.178->0.2.179[/+]asomers commentedon Jan 4, 2026
If you're using the FreeBSD 12 version of
struct statfsfrom libc, but usinggetmntinfo@FBSD_1.0, then that would definitely cause a problem. Why does coreutils define its own FFI binding forgetmntinfoinstead of using the one from libc?oech3 commentedon Jan 4, 2026
I don't know. It was added by different people. libc was bumped to
0.2.178anyway by removing it.But I can't bump to 0.2.179 by i686-musl issue.
[-]Updating libc crate is blocked: 0.2.178->0.2.179[/-][+]stty: Updating libc crate is blocked: 0.2.178->0.2.179[/+]oech3 commentedon Jan 4, 2026
Is this something able to add to
.tomlinstead of environment val?https://github.com/uutils/coreutils/blob/main/.cargo/config.toml This file seems unrecommended.
tgross35 commentedon Jan 4, 2026
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.
oech3 commentedon Jan 4, 2026
#8717 (without those envs) https://github.com/uutils/coreutils/actions/runs/20693102671/job/59404255919?pr=8717#step:13:539
tgross35 commentedon Jan 5, 2026
Looks like that was unintentional breakage from the time_t changes. rust-lang/libc#4913