<div dir="auto"><div><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Tue, Oct 13, 2020, 23:52 Thomas Zimmermann <<a href="mailto:tzimmermann@suse.de">tzimmermann@suse.de</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi<br>
<br>
On Tue, 13 Oct 2020 13:01:58 -0700 Eric Anholt <<a href="mailto:eric@anholt.net" target="_blank" rel="noreferrer">eric@anholt.net</a>> wrote:<br>
<br>
> On Tue, Oct 13, 2020 at 12:08 AM Thomas Zimmermann <<a href="mailto:tzimmermann@suse.de" target="_blank" rel="noreferrer">tzimmermann@suse.de</a>><br>
> wrote:<br>
> ><br>
> > Hi<br>
> ><br>
> > On Fri, 02 Oct 2020 08:04:43 -0700 "Dylan Baker" <<a href="mailto:dylan@pnwbakers.com" target="_blank" rel="noreferrer">dylan@pnwbakers.com</a>><br>
> > wrote:<br>
> ><br>
> > > I have serious concerns about cargo and crate usage. Cargo is basically<br>
> > > npm for rust, and shares all of the bad design decisions of npm,<br>
> > > including linking multiple versions of the same library together and<br>
> > > ballooning dependency lists that are fetched intrigued from the<br>
> > > internet. This is both a security problem and directly in conflict with<br>
> > > meson's design off one and only one version of a project. And while<br>
> > > rust prevents certain kinds of bugs, it doesn't prevent design bugs or<br>
> > > malicious code. Add a meson developer the rust community has been<br>
> > > incredibly hard to work with and basically hostile to every request<br>
> > > we've made "cargo is hour you build rust", is essentially the answer<br>
> > > we've gotten from them at every turn. And if you're not going to use<br>
> > > cargo, is rust really a win? The standard library is rather minimal<br>
> > > "because just pull in 1000 crates". The distro people can correct me if<br>
> > > I'm wrong, but when librsvg went to rust it was a nightmare, several<br>
> > > distros went a long time without u<br>
> >  pdates because of cargo.<br>
> ><br>
> > I can't say much about meson, but using Rust has broken the binaries of<br>
> > several packages on i586 for us; which consequently affects Gnome and KDE.<br>
> > [1][2] Rust uses SSE2 instructions on platforms that don't have them.<br>
> > There's a proposed workaround, but it's not yet clear if that's feasible<br>
> > in practice.<br>
> ><br>
> > Best regards<br>
> > Thomas<br>
> ><br>
> > [1] <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1162283" rel="noreferrer noreferrer" target="_blank">https://bugzilla.opensuse.org/show_bug.cgi?id=1162283</a><br>
> > [2] <a href="https://bugzilla.opensuse.org/show_bug.cgi?id=1077870" rel="noreferrer noreferrer" target="_blank">https://bugzilla.opensuse.org/show_bug.cgi?id=1077870</a><br>
> <br>
> From the first bug:<br>
> <br>
> >Not entirely sure what to do about this. i586 is unsupported by Rust (tier<br>
> >2) and as such the package is built for i686<br>
> <br>
> This really sounds like your distro is just building with the wrong<br>
> rust target for packages targeting an earlier processor.<br>
<br>
Every other language/compiler combination appears to get this right. And even<br>
i686 does not require SSE2. As I said before, there might be a<br>
workaround.<br></blockquote></div></div><div dir="auto"><br></div><div dir="auto">Rust has co-opted i586-unknown-linux-gnu to mean x86-32 without SSE and i686-unknown-linux-gnu to mean x86-32 with SSE2 (technically it implements it by using the pentium4 target cpu, so may require more than just SSE2).</div><div dir="auto"><br></div><div dir="auto">Rust just doesn't provide official binaries for i586-unknown-linux-gnu -- that does not imply that rustc and cargo won't work fine if they are recompiled for i586-unknown-linux-gnu. The only major caveat I'd expect is floats having slightly different semantics due to x87, which may cause some of rustc's tests to fail.</div><div dir="auto"><br></div><div dir="auto">Jacob</div></div>