linux(musl): deprecate LFS64 bindings

[dybucc]

Description

This PR removes support for the exposed LFS64 bindings under Linux musl. This follows from the libc crate's attempts at providing a single, unsuffixed type with which to provide 64-bit functionality.

This follows from #5032, where I understood libc was meant to provide a single, unsuffixed type and not necessarily support aliases (much less conditional aliases.) Upstream musl also defines the LFS64 types routines in terms of the unsuffixed types and routines.

This patch ensures we deprecate these types and the whole musl/lfs64 module in favor of using only the unsuffixed types and routines.

Sources

No specific sources are provided. Running the following command with rg in the main worktree of latest musl should yield search results that show the uniform aliasing mentioned above across all header files.

rg -C 15 -s -uu -g "**/*.h" -e "\\b_LARGEFILE64_SOURCE\\b"

Checklist

• Relevant tests in libc-test/semver have been updated
• No placeholder or unstable values like *LAST or *MAX are included (see #3131)
• Tested locally (cd libc-test && cargo test --target mytarget); especially relevant for platforms that may not be checked in CI

[tgross35]

I haven't yet taken a close look here but I think deprecation of *64 types should hold off until we provide a stable way to enable 64-bit time/offset. I don't think users have great recourse for now - until they can get a 64-bit dirent et al. on 32-bit platforms, this deprecation basically encourages splitting imports into 32- and 64-bit, which doesn't really improve anything on its own.

[dybucc]

I've double-checked the changes in this patch with upstream. There really isn't a difference between unsuffixed types and suffixed types.

musl will just provide 64-bit definitions no matter what. I don't quite understand how does this change not solve the issue altogether. All users, no matter their machine word size or memory model, are already using 64-bit file offset types.

The point being, there's no special treatment as there is with time_t.

[rustbot]

This PR was rebased onto a different main commit. Here's a range-diff highlighting what actually changed.

Rebasing is a normal part of keeping PRs up to date, so no action is needed—this note is just to help reviewers.