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

Fix failed builds on RISC-V (64-bit) #3184

Closed
wants to merge 2 commits into from

Conversation

julianbraha
Copy link

These changes add support for the RISC-V (64-bit) architecture by updating the ioctl-sys dependency, and replacing usage of the ureq crate with reqwest for downloading tldr.

  1. ioctl-sys was updated to support 64-bit RISC-V about 5 months ago, with this commit: codyps/ioctl@295ed33

  2. The ureq crate depends on rustls, which depends on ring. ring does not support RISC-V or other less-popular architectures, which leads to build failures on these systems. The reqwest crate is less architecture-dependent, and can be used to download tldr, instead.

All changes have been tested with cargo test on both x86-64 GNU/Linux, and riscv64 GNU/Linux in QEMU.
x86-64 GNU/Linux has no regressions.
riscv64 GNU/Linux in QEMU succeeds in building, but fails the following tests:

test_cp::test_cp_reflink_insufficient_permission
test_link::test_link_one_argument
test_mv::test_mv_permission_error
test_shred::test_shred_force
test_sort::test_tmp_files_deleted_on_sigint
test_test::test_file_not_owned_by_egid
test_test::test_file_not_owned_by_euid
test_touch::test_touch_permission_denied_error_msg
test_touch::test_touch_system_fails

@@ -28,7 +28,7 @@ uucore = { version=">=0.0.11", package="uucore", path="../../uucore", features=[
walkdir = "2.2"

[target.'cfg(target_os = "linux")'.dependencies]
ioctl-sys = "0.6"
ioctl-sys = { git = "https://github.com/jmesmon/ioctl.git", rev = "295ed33a8704a0eff31bebdcf6ca0bfeb93bf675" }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I am uncomfortable depending on some personal forked git repo.
So, I won't accept this change. Sorry :(
Do you know why it isn't merged upstream + published as a new crate?
thanks

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm not sure why a new release hasn't been made yet, but that repo is actually the upstream, official ioctl-sys.
I'll ask them about updating the crate.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

OK, thanks for codyps/ioctl#22 :)

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

A new crate release was just made and jmesmon/ioctl#22 was resolved, so I've amended commit 4345c2a to use the new version 0.8.0.

@sylvestre
Copy link
Contributor

Cool stuff. Do you know if there is a way to get this tested on a github CI?

@julianbraha
Copy link
Author

I haven't tried it, but there is a QEMU github action: https://github.com/docker/setup-qemu-action
I followed this guide to set up the VM: https://colatkinson.site/linux/riscv/2021/01/27/riscv-qemu/

@sylvestre
Copy link
Contributor

I guess you saw that a few jobs are failing

@julianbraha
Copy link
Author

julianbraha commented Feb 23, 2022

I guess you saw that a few jobs are failing

I've amended the existing commits to fix problems with the spell checker, as well as an outdated Cargo.lock.

There are also some style warnings about existing code that my commits didn't modify.
I'm seeing a number of warning: use of deprecated struct `clap::App`: Replaced with `Command` in src/bin/uudoc.rs

@julianbraha
Copy link
Author

Fixed the style problems. Didn't catch the cargo fmt suggestion earlier.

@julianbraha
Copy link
Author

julianbraha commented Feb 24, 2022

Rebased on #3186 to resolve an unrelated CI error.
Still not sure why I'm getting this:

  Downloaded crossterm v0.23.0
error: failed to parse manifest at `/home/julian/.cargo/registry/src/github.com-1ecc6299db9ec823/crossterm-0.23.0/Cargo.toml`

Caused by:
  feature `edition2021` is required

  this Cargo does not support nightly features, but if you
  switch to nightly channel you can add
  `cargo-features = ["edition2021"]` to enable this feature

After running:

cargo +1.54.0 update
cargo +1.54.0 build

EDIT:
The problem was the cargo +1.54.0 update. For some reason, I thought that updated the Cargo.lock. It does, but it also increases dependency versions unnecessarily.

@julianbraha
Copy link
Author

julianbraha commented Feb 28, 2022

  • Updated the ioctl-sys dependency to use the new crate version, 0.8.0.
  • Resolved CI warnings by (1) rebasing (2) undoing a cargo update (3) removing unecessary use's.

However, it looks like the added openssl dependency from switching to reqwest will cause cross-compilation to fail in the CI.
@sylvestre is it okay to introduce an openssl dependency (and just updated the CI)? Or should I look for another alternative to ureq?

@tertsdiepraam
Copy link
Member

tertsdiepraam commented Feb 28, 2022

Can we get rid of the openssl dependency by using reqwest with rustls by using the rustl-tls feature?

From this bit in the docs it looks like openssl is only used when native tls is used:
https://docs.rs/reqwest/latest/reqwest/#tls

@julianbraha
Copy link
Author

julianbraha commented Feb 28, 2022

Can we get rid of the openssl dependency by using reqwest with rustls by using the rustls-tls feature?

The rustls-tls feature introduces a dependency on ring, which doesn't support RISC-V. This is the same problem with the current ureq crate.

@tertsdiepraam
Copy link
Member

I see. Thanks for checking! Let's review our options:

  1. Make uudoc optional and ignore the fact that it doesn't build on RISC-V (not great)
  2. Use reqwest, introduce the OpenSSL dependency. I think having openssl as a dependency is fine, as long as it doesn't break the CI. So if you can fix that, I would accept this, unless @sylvestre has a different opinion.
  3. Make the download of the examples an optional manual step. So, if you don't download the examples, they won't show up and it will print a warning. If you do have it then it will show up like it does now.
  4. Find some other crate, although we are unlikely to find one that works, because they would need some TLS implementation. Unless there is some crate that just does HTTP without TLS.

2 & 3 are both fine with me.

@@ -252,7 +253,8 @@ lazy_static = { version="1.3" }
textwrap = { version="0.14", features=["terminal_size"] }
uucore = { version=">=0.0.11", package="uucore", path="src/uucore" }
selinux = { version="0.2", optional = true }
ureq = "2.4.0"
reqwest = { version="0.11.9", features = ["blocking"] }
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is pulling a lot of new deps, is it possible to avoid that?

Copy link
Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I'm unaware of any way to reduce the dependencies, besides simply not using reqwest.

We could simply wait for ring to add RISC-V support, and use the existing ureq crate. There's already a PR for this: briansmith/ring#1459

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So you're suggesting that we close this PR? We could create an issue referencing that PR instead.

Copy link
Author

@julianbraha julianbraha Mar 18, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We could close this PR and create a different one if we want to take that route.
The downside is that we would still be depending on ring's architecture support, which is problematic for other systems (see #3216).

I would prefer to try and resolve the CI issues with openssl & cross-compilation instead.

@darleybarreto
Copy link

darleybarreto commented Apr 15, 2022

If I understood correctly, one can disable rustls feature by writing

ureq = { version = "2.4.0", default-features = false, features = ["gzip"]}

Did I miss something?

@julianbraha
Copy link
Author

@darleybarreto the ureq crate will use native-tls in that case, which introduces an openssl system dependency, and breaks cross-compilation builds in the CI (which is the current state of this PR).

I should have some time to look at this again this weekend.

@darleybarreto
Copy link

darleybarreto commented Apr 15, 2022

Oh, I thought native-tls would use something available on any particular platform it supports. I just found an issue on rustls repo about ring. Perhaps pinging them about this issue would be interesting!

tertsdiepraam added a commit to tertsdiepraam/coreutils that referenced this pull request Apr 17, 2022
The ureq dependency is causing compilation errors on various platforms (see uutils#3184, uutils#3216, uutils#3375). Hence we remove that dependency and do not automatically download the archive anymore. Instead, we ask the user to download it separately when the archive is not found.
tertsdiepraam added a commit to tertsdiepraam/coreutils that referenced this pull request Apr 17, 2022
The ureq dependency is causing compilation errors on various platforms (see uutils#3184, uutils#3216, uutils#3375). Hence we remove that dependency and do not automatically download the archive anymore. Instead, we ask the user to download it separately when the archive is not found.
sylvestre pushed a commit that referenced this pull request Apr 17, 2022
The ureq dependency is causing compilation errors on various platforms (see #3184, #3216, #3375). Hence we remove that dependency and do not automatically download the archive anymore. Instead, we ask the user to download it separately when the archive is not found.
@tertsdiepraam
Copy link
Member

tertsdiepraam commented Apr 18, 2022

Closing this as both issues in this PR have been fixed. Thank you for your efforts and for bringing these to our attention!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants