clone_file in src/linux.rs (added in 0.1.2) declares the FICLONE request as libc::c_ulong:
// FICLONE = _IOW(0x94, 9, int) — stable since Linux 4.5.
const FICLONE: libc::c_ulong = 0x4004_9409;
let cloned = unsafe { libc::ioctl(dest_file.as_raw_fd(), FICLONE, src_file.as_raw_fd()) } == 0;
libc::ioctl's request parameter is libc::Ioctl, which is c_ulong on glibc but c_int on musl, so the crate fails to compile for every *-unknown-linux-musl target:
error[E0308]: mismatched types
--> decmpfs-0.1.2/src/linux.rs:296:60
|
296 | let cloned = unsafe { libc::ioctl(dest_file.as_raw_fd(), FICLONE, src_file.as_raw_fd()) } == 0;
| ----------- ^^^^^^^ expected `i32`, found `u64`
| |
| arguments to this function are incorrect
|
note: function defined here
--> libc-0.2.186/src/unix/linux_like/mod.rs:1731:20
|
1731 | pub fn ioctl(fd: c_int, request: Ioctl, ...) -> c_int;
error: could not compile `decmpfs` (lib) due to 1 previous error
Reproduce: cargo build --target x86_64-unknown-linux-musl (or aarch64-unknown-linux-musl) on 0.1.2. glibc, macOS, and Windows targets are unaffected.
Fix: cast at the call site, the way the other ioctls in the same file already do — libc::ioctl(dest_file.as_raw_fd(), FICLONE as _, src_file.as_raw_fd()) — or type the constant as libc::Ioctl. The comment above FS_IOC_GETFLAGS in that file already documents this exact hazard:
// `as _` at the call site casts it to whatever `libc::ioctl` expects per target
// (c_ulong on glibc, c_int on musl) — same 32 bits either way.
clone_file is the only ioctl call site in the file that omits the cast, so 0.1.0 built fine on musl and 0.1.2 does not. Still present on main at crates/decmpfs/src/linux.rs:295.
Context: this reached us as musl CI failures in jdx/aube after a lockfile bump to 0.1.2; we've pinned back to 0.1.0 for now. Happy to send a PR if that's useful.
This issue was generated by Claude.
clone_fileinsrc/linux.rs(added in 0.1.2) declares theFICLONErequest aslibc::c_ulong:libc::ioctl's request parameter islibc::Ioctl, which isc_ulongon glibc butc_inton musl, so the crate fails to compile for every*-unknown-linux-musltarget:Reproduce:
cargo build --target x86_64-unknown-linux-musl(oraarch64-unknown-linux-musl) on 0.1.2. glibc, macOS, and Windows targets are unaffected.Fix: cast at the call site, the way the other ioctls in the same file already do —
libc::ioctl(dest_file.as_raw_fd(), FICLONE as _, src_file.as_raw_fd())— or type the constant aslibc::Ioctl. The comment aboveFS_IOC_GETFLAGSin that file already documents this exact hazard:clone_fileis the only ioctl call site in the file that omits the cast, so 0.1.0 built fine on musl and 0.1.2 does not. Still present onmainatcrates/decmpfs/src/linux.rs:295.Context: this reached us as musl CI failures in jdx/aube after a lockfile bump to 0.1.2; we've pinned back to 0.1.0 for now. Happy to send a PR if that's useful.
This issue was generated by Claude.