Rust and GCC, two different ways [LWN.net]

Rust and GCC, two different ways

Posted Oct 4, 2021 16:17 UTC (Mon) by TheGopher (subscriber, #59256)
Parent article: Rust and GCC, two different ways

I feel I’m often missing a critical discussion of LLVM and the risk of binary only distribution; where the compiler source is not available and architecture specific patches are unavailable to developers. I consider this a driving concern when it comes to requiring gcc support for rust before considering it for general use.

to post comments

Rust and GCC, two different ways

Posted Oct 4, 2021 19:30 UTC (Mon) by josh (subscriber, #17465) [Link] (3 responses)

While it's theoretically possible for some architecture vendor or third party to ship a proprietary LLVM, and to ship a proprietary rustc based on that LLVM, rustc will never have official support for any target that requires a proprietary backend, so such a target would always be a permanent fork. (Source: I wrote rustc's policy for accepting new targets.)

Adding gcc support for Rust will not prevent or in any way affect the possibility of proprietary forks; those forks would just not use GCC.

Rust and GCC, two different ways

Posted Oct 4, 2021 20:41 UTC (Mon) by TheGopher (subscriber, #59256) [Link] (2 responses)

From what I've heard (but please correct me if I'm wrong) Apple already ships an LLVM with proprietary extensions/patches, though I don't know to what degree the patches are architecture specific.

I personally think the best strategy for maintaining a world of free compilers is to ensure we focus on GCC whenever possible, though not excluding LLVM as the competition is healthy.

Rust and GCC, two different ways

Posted Oct 4, 2021 21:25 UTC (Mon) by josh (subscriber, #17465) [Link] (1 responses)

> From what I've heard (but please correct me if I'm wrong) Apple already ships an LLVM with proprietary extensions/patches, though I don't know to what degree the patches are architecture specific.

Apple *appears* to ship LLVM source code, and maintain a public repository. Their patches aren't upstream, but it doesn't look like they're proprietary, unless they're adding further patches atop the public sources before shipping the version in the xcode SDK.

The issue with Apple appears to be more that their build-and-sign toolchain and requirements are based on their "bitcode" format which uses a specific version of LLVM, and using a newer toolchain produces things Apple's infrastructure won't accept.

> I personally think the best strategy for maintaining a world of free compilers is to ensure we focus on GCC whenever possible, though not excluding LLVM as the competition is healthy.

LLVM exists. You can't prevent people from building proprietary compilers atop it; the existence of GCC doesn't prevent that, only the non-existence of competing permissively licensed compilers would prevent that, and that isn't going to happen.

We can't prevent the existence of proprietary compilers; all we can do is reject them when they arise, and ensure that everything upstream is Open Source.

Rust and GCC, two different ways

Posted Oct 5, 2021 5:41 UTC (Tue) by joib (subscriber, #8541) [Link]

> Apple *appears* to ship LLVM source code, and maintain a public repository. Their patches aren't upstream, but it doesn't look like they're proprietary, unless they're adding further patches atop the public sources before shipping the version in the xcode SDK.

I haven't checked, but from what I've heard they haven't published things like the pipeline description tables for their ARM chips, nor support for the matrix instructions in the M1.