Create a separate target for illumos #55553
Comments
|
@nagisa what's the best way for illumos rustc/cargo builds to make their way into rustup? |
nagisa
added
A-target-specs
|
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 |
|
A recent example of what it takes to add a target to rustc can be found here |
|
@rust-lang/infra more than release :) |
|
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? |
|
@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? |
|
Awesome!
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. |
|
As an FYI, I'm picking up this work from @jasonbking. I've rebased and fixed up his progress in a new branch: pfmooney/rust#illumos-triple. I'm currently accumulating a series of PRs to go into crate dependencies so rustc and all the necessary tools can be cross compiled in an environment similar to the other platforms. |
|
Once the referenced PRs are merged, and corresponding package versions are cut in order to update the cargo/rustup dependencies, I believe most of what we need will be in place. Work on a cross-compile CI process is ongoing between @jclulow and I. Necessary component PRs:
|
Update dependencies to support illumos target Several dependencies of cargo require updates in order to build with illumos as the `target_os` platform (rust-lang/rust#55553). Most are patch revisions to include `#[cfg()]` updates. In the case of `fs2`, the maintainer does not appear to be minding activity on the project, so it was forked into `fs3`, maintaining the same interfaces and logic (but featuring the widened platform support).
Add illumos triple This fixes rust-lang#55553 and adds support for `illumos` as a `target_os` on `x86_64`. In addition to the compile spec and libstd additions, several library dependencies have been bumped in order to permit working builds of cargo and rustup for the new target. Work originally started by @jasonbking, with subsequent additions by @pfmooney and @jclulow.
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.
The text was updated successfully, but these errors were encountered: