Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for MIPS architectures in Travis #684

Closed
wants to merge 1 commit into from

Conversation

mpapierski
Copy link

This adds mips/mips64/mipsel/mips64el targets to the build system.

Unfortunately travis trusty image doesn't ship with gcc-mips*
packages. On these platforms cargo is replaced with cross1 to run
those builds on a docker container.

For now all MIPS tests are allowed to fail to make way for future PRs
that will fill the gaps.

This is a first step to bring support to MIPS platforms (#562).

Note that the with this commit matrix really grew up to about 168 builds. This is fine since we have 'fast_finish(no waiting forallow_failures` builds).

I'm still waiting for a full build to finish on my fork (https://travis-ci.org/mpapierski/ring). Note that at first I've disabled few tests just to make way for mips builds, and I plan to re-run cancelled tests that are known to be green just to make sure everything works as expected.

Expected failure on all mips architectures:

--- stderr
thread 'main' panicked at 'called `Option::unwrap()` on a `None` value', libcore/option.rs:335:21
note: Run with `RUST_BACKTRACE=1` for a backtrace.

This adds mips/mips64/mipsel/mips64el targets to the build system.
Unfortunately travis `trusty` image doesn't ship with `gcc-mips*`
packages. On these platforms `cargo` is replaced with `cross`[1] to run
those builds on a docker container.

For now All MIPS tests are allowed to fail to make way for future PRs
that will fill the gaps.

This is a first step to bring support to MIPS platforms.

[1]: https://github.com/japaric/cross
@mpapierski mpapierski changed the title Add support for MIPS architectures. Add support for MIPS architectures in Travis Aug 1, 2018
@mpapierski mpapierski mentioned this pull request Aug 4, 2018
@briansmith
Copy link
Owner

OK, looking at this, it seems like MIPS is a lot more expensive to support than I expected.

Is there really no alternative to using docker and the cross toolkit? I think that on other targets we use sudo: true and then install packages. I would prefer to keep MIPS more like the other platforms if at all possible.

@mpapierski
Copy link
Author

@briansmith Instead of running builds through cross it could be probably achieved in a smiliar way by specifying linker to a cross compiling one, and the runner would be qemu-$ARCH. That would work. Anyway, I'd still recommend cross as it saves a lot of headaches. We have lots of successes with it especially when dealing with MIPS and big endian. We even run x86 tests through cross.

@briansmith
Copy link
Owner

OK, looking at this, it seems like MIPS is a lot more expensive to support than I expected.

Is there really no alternative to using docker and the cross toolkit? I think that on other targets we use sudo: true and then install packages. I would prefer to keep MIPS more like the other platforms if at all possible.

I have decided, at least for now, to use cross for all targets except i686 and x86_64. I've extended your PR to support this on this branch: https://travis-ci.org/briansmith/ring/builds/468249568 and I'll merge it once CI passes.

@pietro
Copy link
Contributor

pietro commented Jan 20, 2019

@mpapierski @briansmith Travis now has a Xenial environment that so we can use it for cross compiling mips. I'll add it to nightly only on a branch in my fork. This way it will only add 8 more builds instead of 24.

@briansmith briansmith changed the base branch from master to main June 19, 2020 17:09
@briansmith
Copy link
Owner

I had to move away from Travis CI to GitHub Actions. Further, I learned a lot about how to do this cross-compilation stuff so that we don't need to use cross. So, this PR is obsolete and I'm going to close it. It isn't your fault; I just didn't get to it in a timely manner. Thanks for contributing this. I will update issue #562 with my current plans.

@briansmith briansmith closed this Nov 24, 2020
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants