Yes, and no, you're right the std library's might be affected by this in some way (at least I believe it might but I haven't seen an actual problem using the libstd-rs recipe), either way, if a problem arises its easily solvable because that's actually one of the features that comes with this, the build-std feature builds the std library as part of the crate compilation process, this way you end up with a newly built corresponding std library.
On Mon, Dec 19, 2022, 4:24 AM Alex Kiernan <[email protected]> wrote: > On Sat, Dec 17, 2022 at 4:21 PM Alejandro Hernandez Samaniego > <[email protected]> wrote: > > > > From: Alejandro Hernandez Samaniego <[email protected]> > > > > Rust follows the train release model via the stable, beta and nightly > channels, > > by default we build rust from the stable channel, however there are > certain > > features which are only available in the beta or nightly channels. > > > > Make these channels available by setting a RUST_CHANNEL variable which > defaults > > to stable making this change transparent to the user. > > > > The snapshot version used by rust during its compilation wont > necessarily match > > the version being built, specially if were building from an unstable > channel, > > to avoid confusion rename this to SNAPSHOT_VERSION and use RUST_VERSION > for the > > version to be built, which is automatically defined to PV. > > > > Append -beta or -nightly to rusts PV for signature awareness. > > > > It is important to note that this does not build rust from the > beta/nightly > > published tarball (which today build rust v1.67.0 and v1.68.0 > respectively), > > instead this builds rust from the current selected version (1.66.0) and > enables > > the beta/nightly features for that version. > > > > Setting the variable RUST_CHANNEL=nightly results in the following: > > > > $ rustc -Vv > > rustc 1.66.0-nightly > > > > I think there's an existing problem which means you're probably still > not getting quite what you wanted here... I think libstd-rs build > ought to be affected by this, but as far as I can tell won't be, > because we're building it with cargo, not as part of the bootstrap > process (and I've failed to find any documentation which suggests > building with cargo is "supported"). I've no idea if that means you > could end up with something which is subtly broken. > > That said, my attempts to switch the way the standard library gets > built over the weekend failed miserably. > > -- > Alex Kiernan >
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#174820): https://lists.openembedded.org/g/openembedded-core/message/174820 Mute This Topic: https://lists.openembedded.org/mt/95731773/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
