Create a separate target for illumos

[nagisa]

Illumos seems to be becoming less and less similar to its ancestor – Solaris. There are multiple incompatibilities at the OS interface level – rust-random/rand#637 and #52577 are the things that come to mind, but I’m sure there are more and the differences will keep coming up more and more frequently as the two diverge over time.

[papertigers]

@nagisa what's the best way for illumos rustc/cargo builds to make their way into rustup?
Someone mentioned we would need a Dockerfile in rust/src/ci/docker/ that is capable of cross compiling. Is that the correct way forward? If so, we may need to look into the illumos triple sooner. Regardless it would be nice to be able to support rustup in addition to installing via pkgsrc on illumos based systems.

[nagisa]

First, a proper target to rustc needs to be added. This is fairly easy to do since a very similar target (for solaris) already exists and can be mostly copied over for the illumos one.

This would allow building code targeting illumos specifically, but would not result in builds available for download via rustup or direct download quite yet.

Given that no C/C++ compilers make a distinction between solaris and illumos targets yet, Solaris’ docker image could most likely be reused for building illumos rustc. All that would be necessary to produce tarballs of rustc+stdlib+tools then boils down to an additional entry in our .travis.yml, I think. The @rust-lang/release would know better here, though!

[nagisa]

A recent example of what it takes to add a target to rustc can be found here

[pietroalbini]

@rust-lang/infra more than release :)

[jasonbking]

After resolving some other issues, we've started working on this. One issue we've run into though, is with the current rust beta, one cannot merely define a new target spec and then build rust to support that target, as there are now interdependencies with other crates during the build (libc particularly, though it also looks like num_cpus and rand are also needed). It seems unlikely we could coordinate integrating support to those crates simultaneously. Even if we could, there is still the issue that the crate versions uses would also need to be updated accordingly -- any ideas how one would go about doing that? It seems unlikely that other crates would add support for a non-existent target, so any ideas how to solve the chicken and egg problem? Should we proceed with a PR for the illumos target, even if it can't be built until after the dependent crates are updated?

[papertigers]

@nagisa we are looking at driving this forward again. There is work in https://github.com/jasonbking/rust/tree/illumos that needs to be rebased before we can open a PR.

That being said we are running into issues where rust requires multiple versions of different crates such as rand. Where some versions of rand have a bug fixed for illumos but some parts of rust pull in an older versions of the crate. How should we move forward on that front? Open new issues/PRs on this project to unify the many versions of rand? And if so should we have a new github label called "illumos" to help track this progress?

[nagisa]

Awesome!

How should we move forward on that front? Open new issues/PRs on this project to unify the many versions of rand?

Updating just the old (non-working) versions of rand should be sufficient. I think it is fine for it to happen as part of the whole PR that introduces illumos support, but it is also fine to split the work in smaller pieces and submit upgrades to rand to upstream – here – first.