platform-support/netbsd.md: No longer mention 9.x, due to EoL. #162268
+3
−3
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
|
|
@@ -25,10 +25,10 @@ are currently defined running NetBSD: | |
|
|
||
| All use the "native" `stdc++` library which goes along with the natively | ||
| supplied GNU C++ compiler for the given OS version. Most of the bootstraps | ||
| are built for NetBSD 10.x, although some exceptions exist (some are | ||
| built for newer NetBSD versions, due to target becoming usable first | ||
| with newer versions). `x86_64-unknown-netbsd` is built for NetBSD | ||
| 11.x to access a newer gcc. | ||
|
Comment on lines
30
to
+31
Member
There was a problem hiding this comment. Is there a PR in the works for this? Currently it looks like 10 is still used
Member
There was a problem hiding this comment. I have no preference whether or not it's changed, just want our docs to be consistent
Author
There was a problem hiding this comment.
Looks like the maintainer has replied, so striking my comment out. |
||
|
|
||
|
|
||
| ## Target Maintainers | ||
|
|
@@ -38,7 +38,7 @@ with newer versions). `x86_64-unknown-netbsd` is built for NetBSD | |
|
|
||
| Further contacts: | ||
|
|
||
| - [NetBSD/pkgsrc-wip's rust](https://github.com/NetBSD/pkgsrc-wip/blob/master/rust198/Makefile) maintainer (see MAINTAINER variable). This package is part of "pkgsrc work-in-progress" and is used for deployment and testing of new versions of rust. Note that we have the convention of having multiple rust versions active in pkgsrc-wip at any one time, so the version number is part of the directory name, and from time to time old versions are culled so this is not a fully "stable" link. | ||
| - [NetBSD's pkgsrc lang/rust](https://github.com/NetBSD/pkgsrc/tree/trunk/lang/rust) for the "proper" package in pkgsrc. | ||
| - [NetBSD's pkgsrc lang/rust-bin](https://github.com/NetBSD/pkgsrc/tree/trunk/lang/rust-bin) which re-uses the bootstrap kit as a binary distribution and therefore avoids the rather protracted native build time of rust itself | ||
|
|
||
|
|
||
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Uh oh!
There was an error while loading. Please reload this page.
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.
Could you make the supported version explicit with an "OS version" section, like we have here? https://doc.rust-lang.org/nightly/rustc/platform-support/apple-darwin.html#os-version
View changes since the review
Uh oh!
There was an error while loading. Please reload this page.
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.
@tgross35 the whole 10.x series is binary compatible, i.e. it doesn't really matter if you build on 10.0 and are using 10.1 or the reverse.
Edit: thoughts @he32 ?
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'm not sure what exactly that is in response to but to clarify, I'm just looking for an explicit "The minimum supported version is ..." sentence rather than inferring what "most of the bootstraps are built for" means.
And/or adding a
(x.y+)note to the table on https://doc.rust-lang.org/nightly/rustc/platform-support.html like a lot of platforms haveUh oh!
There was an error while loading. Please reload this page.
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.
Alright, let me go through the tooling and get the exact numbers out.Looks like both the maintainers have replied, so striking my comment out.
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.
That's understandable... However, that is also a moving target, and depends on the rust version, well, really depends on the minimum supported LLVM version and/or the integrated LLVM version. So far (as of this writing, 1.98.1 is released), the new LLVM version (23.x?) which requires an "insanely fresh gcc to build correctly" and which pushes the minimum OS version target upwards has so far not materialized in a full rust release. It's due for the next one? So I hesitate to bump the minimum requirement for the base OS while we still build releases for 9.x (which results in binaries which can be run on both 10.x and 11.x).
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.
The version we use for building can also be decoupled from the version we support. We should be able to bump build dependencies if something blocks it, but produce a rustc and other compiled binaries that work on older targets (like we do for many other platforms).
To be clear: I personally have no problem with whatever minimum version is picked and am not pushing for a bump, 8 or 9 or 10 or 11 makes no difference to me. We just need a clear answer for what we're trying to support so we can make decisions like what to do with rust-lang/libc#5243.
Uh oh!
There was an error while loading. Please reload this page.
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.
Well, it's a bit more complicated than that.
In general, a binary built on 9.x can be run on 10.x and 11.x.
A binary built on 10.x on the other hand, all bets are off for being able to run it on 9.x.
Similarly, a binary built on 11.x there is no guarantee it will be possible to run on either of 10.x or 9.x.
There's some additional rules for what goes between 10.0 and subsequent 10.x versions such as 10.1, but that gets into the weeds and is probably not so relevant here.
So stating what version we build binaries for actually already specifies which versions the resultant binaries are usable on. That's also part of the reason that I don't want to prematurely bump the minimum supported OS version, and also why I stick to the oldest supported version in my target trees when doing cross compilation.
And, lastly, since rust requires a binary for the "previous" rust version to bootstrap, bumping the OS version we build for will cut off all lower-major-numbered OS releases from having any chance of getting rust installed, at least for a "native" build (I realized a cross-build could still be done, as long as the target's compiler is new enough, ref. the impending increase in requirement on that front for newer LLVM).