-
Notifications
You must be signed in to change notification settings - Fork 1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
build.rs: always use freebsd12 when rustc_dep_of_std is set #3723
Conversation
Thanks for the pull request, and welcome! The Rust team is excited to review your changes, and you should hear from @JohnTitor (or someone else) some time within the next two weeks. 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 (
|
8dabe1d
to
b3d5f22
Compare
@JohnTitor any chance of seeing a libc release with this change any time soon? That should allow a bit of cleanup in Miri. :) |
Oh, I didn't realize that the branch for releases on crates.io is separate from |
The branches are unfortunately pretty divergent, so I have just been requesting everyone to always target I'll get this into a release within the next couple of days. |
Okay cool, thanks :)
…On August 17, 2024 8:40:48 PM UTC, Trevor Gross ***@***.***> wrote:
The branches are unfortunately pretty divergent, so I have just been requesting everyone to always target `main` and ***@***.*** label +stable-nominated` for things that should get backported. I cherry pick them in batches.
I'll get this into a release within the next couple of days.
--
Reply to this email directly or view it on GitHub:
#3723 (comment)
You are receiving this because you modified the open/close state.
Message ID: ***@***.***>
|
(backport <rust-lang#3723>) (cherry picked from commit b358c8f)
(backport <rust-lang#3723>) (cherry picked from commit b358c8f)
@RalfJung this should be available in 0.2.157 now |
match which_freebsd() { | ||
Some(10) if libc_ci => set_cfg("freebsd10"), | ||
Some(11) if libc_ci => set_cfg("freebsd11"), | ||
Some(12) if libc_ci || rustc_dep_of_std => set_cfg("freebsd12"), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just realized the previous logic for rustc_dep_of_std here wasn't what I thought it was...
The logic was: if the auto-detected version is 12 and rustc_dep_of_std
is set, then use freebsd12
. If the auto-detected version is anything else and rustc_dep_of_std
is set, use freebsd11
. If this was deliberate, I don't understand why, and it doesn't match the comments.
With my PR, the logic now is: if rustc_dep_of_std
is set, don't even auto-detect, just use version 12. This matches what the comments already said before.
library: bump libc dependency This pulls in rust-lang/libc#3723, which hopefully unblocks rust-lang/miri#3748.
library: bump libc dependency This pulls in rust-lang/libc#3723, which hopefully unblocks rust-lang/miri#3748.
library: bump libc dependency This pulls in rust-lang/libc#3723, which hopefully unblocks rust-lang/miri#3748.
library: bump libc dependency This pulls in rust-lang/libc#3723, which hopefully unblocks #3748.
readdir_r shim: assume FreeBSD v12+ Blocked on rust-lang/libc#3723 being released and propagating to std.
readdir_r shim: assume FreeBSD v12+ Blocked on rust-lang/libc#3723 being released and propagating to std.
readdir_r shim: assume FreeBSD v12+ Blocked on rust-lang/libc#3723 being released and propagating to std.
Commit 7437d0a erroneously defined it as "ulong" instead of u64. Nobody noticed the mistake, probably because it was only tested on 64-bit architectures, where those are equivalent. But it's a problem now, after rust-lang#3723 , which switched the standard library to a FreeBSD 12 ABI. Issue rust-lang/rust#130677
The original definitions were never correct. But nobody noticed because we don't do CI on 32-bit FreeBSD. The problem is apparent now due to rust-lang#3723 , which caused the nightly toolchain to switch to a FreeBSD 12 ABI. Fixes rust-lang/rust#130677
The original definitions were never correct. But nobody noticed because we don't do CI on 32-bit FreeBSD. The problem is apparent now due to rust-lang#3723 , which caused the nightly toolchain to switch to a FreeBSD 12 ABI. Fixes rust-lang/rust#130677
The original definitions were never correct. But nobody noticed because we don't do CI on 32-bit FreeBSD. The problem is apparent now due to rust-lang#3723 , which caused the nightly toolchain to switch to a FreeBSD 12 ABI. Fixes rust-lang/rust#130677
* Fix the definition of ino_t on 32-bit FreeBSD 12+ Commit 7437d0a erroneously defined it as "ulong" instead of u64. Nobody noticed the mistake, probably because it was only tested on 64-bit architectures, where those are equivalent. But it's a problem now, after #3723 , which switched the standard library to a FreeBSD 12 ABI. Issue rust-lang/rust#130677 * Fix the definition of "struct stat" on 32-bit FreeBSD 12+ The original definitions were never correct. But nobody noticed because we don't do CI on 32-bit FreeBSD. The problem is apparent now due to #3723 , which caused the nightly toolchain to switch to a FreeBSD 12 ABI. Fixes rust-lang/rust#130677 * fixup: fix build on powerpc, powerpc64, and arm
Commit 7437d0a erroneously defined it as "ulong" instead of u64. Nobody noticed the mistake, probably because it was only tested on 64-bit architectures, where those are equivalent. But it's a problem now, after rust-lang#3723 , which switched the standard library to a FreeBSD 12 ABI. Issue rust-lang/rust#130677
The original definitions were never correct. But nobody noticed because we don't do CI on 32-bit FreeBSD. The problem is apparent now due to rust-lang#3723 , which caused the nightly toolchain to switch to a FreeBSD 12 ABI. Fixes rust-lang/rust#130677
Commit 7437d0a erroneously defined it as "ulong" instead of u64. Nobody noticed the mistake, probably because it was only tested on 64-bit architectures, where those are equivalent. But it's a problem now, after rust-lang#3723 , which switched the standard library to a FreeBSD 12 ABI. Issue rust-lang/rust#130677
The original definitions were never correct. But nobody noticed because we don't do CI on 32-bit FreeBSD. The problem is apparent now due to rust-lang#3723 , which caused the nightly toolchain to switch to a FreeBSD 12 ABI. Fixes rust-lang/rust#130677
Commit 7437d0a erroneously defined it as "ulong" instead of u64. Nobody noticed the mistake, probably because it was only tested on 64-bit architectures, where those are equivalent. But it's a problem now, after rust-lang#3723 , which switched the standard library to a FreeBSD 12 ABI. Issue rust-lang/rust#130677
The original definitions were never correct. But nobody noticed because we don't do CI on 32-bit FreeBSD. The problem is apparent now due to rust-lang#3723 , which caused the nightly toolchain to switch to a FreeBSD 12 ABI. Fixes rust-lang/rust#130677
Currently, when rustc_dep_of_std is set, the freebsd version used depends on the return value of
which_freebsd()
:Some(12)
, it usesfreebsd12
freebsd11
That does not seem intended? It is certainly rather odd that when building on FreeBSD 13 we'd get the freebsd11 API, but when building on FreeBSD 12 we get freebsd12. This also causes some "fun" for Miri when cross-building the freebsd std on other targets:
which_freebsd()
then returnsNone
, so std uses different symbols than it does in the std that is shipped by rustup.I assume the intention of #3434 was to force std to use freebsd12 when rustc_dep_of_std is set (at least that's what the comments seem to say), so let's implement that.