Don't use LFS64 symbols on musl

[git-bruh]

Supersedes #106246

Note to packagers: If your distro's musl package has already been updated, then you won't be able to build a newer version of rust until a new rust release is made with these changes merged (which can be used to bootstrap). I'm using a super hacky method to bypass this by creating a stub library with LFS64 symbols and building a patched rust, so the symbols satisfy the build requirements while the final compiler build has no references to LFS64 symbols, example: https://codeberg.org/kiss-community/repo/pulls/160/files Doesn't seem to be necessary with new rustup nightly builds, likely due to updates to vendored crates

cc @alyssais

[rustbot]

Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @m-ou-se (or someone else) soon.

Please see the contribution instructions for more information. Namely, in order to ensure the minimum review times lag, PR authors and assigned reviewers should ensure that the review label (S-waiting-on-review and S-waiting-on-author) stays updated, invoking these commands when appropriate:

• @rustbot author: the review is finished, PR author should check the comments and take action accordingly
• @rustbot review: the author is ready for a review, this PR will be queued again in the reviewer's queue

[git-bruh]

Working on fixing the errors

[git-bruh]

1. I noticed that the alternative DirEntry struct had a comment saying // The full entry includes a fixed-length d_name., and musl's dirent struct satisfies that requirement, but doing this would require swapping to the alternative next impl for the ReadDir iterator, which further uses readdir_r, which is apparently deprecated so I just let it be the way it already was, using the DirEntry implementation with a heap-allocated copy of name like most other platforms

2. All the #[cfg] conditions are structured like all(target_os = "linux", not(target_env = "musl")) rather than just target_env = "musl" for consistency

3. I might've gotten a bit lost trying to compute all the any(not(...))'s in my head during the refactor of kraj's changes but I did re-check a couple of times

[git-bruh]

Actually, now that the libc crate aliases all functions and their *64 counterparts to the same symbol on musl, this shouldn't really be necessary rust-lang/libc@1e8c55c, can someone else confirm? The only issue would be that older official rust-std releases built against an older libc crate (which is the case with 1.71.0 binaries, which got me confused, but likely not with 1.72.0 and above) would be tainted with these symbols, which can be worked around with the hack described in my original comment.

[bors]

☔ The latest upstream changes (presumably #115230) made this pull request unmergeable. Please resolve the merge conflicts.

[workingjubilee]

Actually, now that the libc crate aliases all functions and their *64 counterparts to the same symbol on musl, this shouldn't really be necessary rust-lang/libc@1e8c55c, can someone else confirm?

I think not but I would be happy to accept cleanup PRs that make us stop relying on that libc hack, assuming this was rebased.

The only issue would be that older official rust-std releases built against an older libc crate (which is the case with 1.71.0 binaries, which got me confused, but likely not with 1.72.0 and above) would be tainted with these symbols, which can be worked around with the hack described in my original comment.

Partially because of that, yeah.

[git-bruh]

Rebased again, bit tricky to test it though. Will probably try to locally revert the lfs64 patch in rust's bundled libc crate and see if this compiles successfully

[workingjubilee]

I think we can take this in and follow up if we've found we missed one.

[workingjubilee]

Thanks!
@bors r+

[bors]

📌 Commit 65475f5 has been approved by workingjubilee

It is now in the queue for this repository.

[bors]

⌛ Testing commit 65475f5 with merge cbbd524...

[bors]

💔 Test failed - checks-actions

[git-bruh]

weird, any idea what the failure is about? doesn't seem to be related to the PR

[workingjubilee]

...huuuh. Weird. Can you give this another rebase just to be sure?

[workingjubilee]

@bors r+

[bors]

📌 Commit 7a504cc has been approved by workingjubilee

It is now in the queue for this repository.

[workingjubilee]

I'm assuming the previous failure was spurious, however, I asked for a rebase because the only thing that explained the error, to me, was a mismatch due to one of the recent "format a ton of stuff" PRs.