Followup-For: Bug #973414 X-Debbugs-Cc: fierel...@gmail.com On Mon, 3 Apr 2023 23:07:35 +0200, Fierelier wrote: > * In terms of confusion: I think using the Rust i586 toolchain, and > building for i586 with Rust might be less confusing, because altering > the i686 definitions for rustc will make it act differently compared > to other platforms. People could compile code for i686 on Debian, get > working code, but then if someone else does the same on another > distro, the produced binary would not work on the same devices.
That's a fair point, yep; matching upstream behaviour is often the simplest and most understandable approach. It seems the choice is between using an upstream-compatible definition, or an inter-toolchain-compatible definition (are there any other choices? I did notice use of per-extension feature flags in some build configurations. they don't appear widely standardized though, or at least that's my initial sense). > Although, I think changing the i686 definition down, like you did, is > the most accurate way to achieve the goal, and is what I personally > think should be mainline. If the accurate definition proves itself on > Debian, it might find itself in mainline Rust, too, which would be > awesome. Thanks - and thank you for re-stating the intent of the patch. (I confusingly wrote "my personal preference" instead of "my personal opinion" in a previous comment) I wouldn't want Debian's choice to be intended as a way to influence Rust's upstream choices. It'd be more a case of "who is comfortable using a divergent definition of "i686" for longer before their respective communities call them out on it" (in other words: each project can take their own path, and each project can decide how to proceed, as they usually would).
