I’m curious what the community opinion is about the target triples. For instance, the rust-lang.org binaries use a triple like x86_64-unknown-linux-gnu, where the vendor is “unknown”. We could fill that with “redhat” for Fedora, but I’m not sure whether we should.
There’s precedence both ways in the C compilers. Fedora’s GCC targets x86_64-redhat-linux, and its clang targets x86_64-unknown-linux-gnu just like Rust.
I worry that filling in the vendor might unnecessarily fork configurations in things like Cargo’s platform specific dependencies. Surely we don’t want upstream authors to have to list every vendor variation under the sun, and it seems like a silly thing to have to patch for distro packaging a crate. Plus we want the distro compiler to be usable for developers to compile external unpatched crates too.
Perhaps there’s an LLVM reason for leaving it unknown too? That could be why Fedora’s clang is not vendored, but I’m not familiar with LLVM internals.
So I’m leaning toward leaving Rust “unknown”. What do you think?
In my view, platform triples used in paths and in Cargo should not include the vendor aspect of the platform triple but you should compile with the vendor in your platform triple.
Thus, x86_64-redhat-linux-gnu should be equivalent to x86_64-linux-gnu, and the latter form should be used in paths and in Cargo platform specific dependencies.
The whole point of the “vendor” is to provide for informational purposes some idea of the compiler “profile” used to build the software. For example, x86_64-mageia-linux-gnu implies that the software was built on Mageia, and likely includes Mageia’s defaults for compilers, library options, etc.
That information is useful for debugging purposes when trying to identify issues caused by different configurations.
I would strongly suggest that you do preserve the vendor (in your case redhat) and just ensure that the paths and Cargo are set up to use non-vendored triples (or alias it to unknown or pc vendor if the vendor must remain in the triple for Cargo registry and file paths for libraries and rust packages).
With respect to Cargo, the new ability to use cfg expressions rather than naming explicit triples should hopefully make the concern there not as large as it should be. People should hopefully be using [target.'cfg(target_os = "linux")'.dependencies] rather than [target.x86_64-unknown-linux-gnu.dependencies][target.x86-unknown-linux-gnu.dependencies].
So, I think they're both good ideas, making the tools vendor-agnostic and moving to "pc" instead of "unknown". But I think this support has to come from above, not starting in Fedora. For now, I'm going to leave it alone, and we may try to vendorize in the future.
I think this could be helped in other ways. GCC writes a .comment section with the compiler version, including vendor info, and also command line options that affect codegen are stored in DW_AT_producer (with -grecord-gcc-switches).
That does not account for changes to the compiler itself (through patches in the compiler, standard library, etc.). The vendor helps you get an idea of which compiler was used, which can give you a hint to go look at a particular vendor's compiler's behavior. It may not happen so often anymore, but when it is necessary, it is extremely handy.
If you're properly building the Rust environment for a distro (from source, integrated with the system), you should absolutely vendorize. This goes for any language environment. The language environment itself should ignore the vendor part of the platform triple in its tooling, but should allow you to set it properly.
Sure it does, even better than just knowing the vendor is "redhat". For instance, on one binary here I get a producer like "GNU C++14 6.1.1 20160621 (Red Hat 6.1.1-3) -mtune=generic -march=x86-64 -g -O2 -fno-PIE -fstack-protector-strong -fprofile-use -fno-exceptions -fno-rtti -fasynchronous-unwind-tables --param ssp-buffer-size=4". This tells me the exact GCC used, including that it was distro release 3, and a lot of relevant options.
When Rust itself is ready for this, I'm willing to vendorize our target. Care to file an issue or RFC?
I meant an issue or RFC with Rust, not Fedora, in case that wasn’t clear. I think it probably is substantial enough of a change to warrant an RFC. See CONTRIBUTING.md and the rust-lang/rfcs repo.
Once that’s resolved, then for Fedora we can discuss it informally or on bugzilla.redhat.com.