KUKSA.val databroker fails to build for RISC-V platforms

Description

While testing the fix for , it was observed that the databroker fails to build for qemuriscv64.  Upon investigation, the root cause is a crate ("ring") in the dependency hierarchy that builds and wraps C and asm cryptography implementations.  This issue will track working up a fix/workaround to get the databroker to build.  Initial investigation indicates:

  • The ring crate does not have RISC-V support upstream, but there have been several different pull requests with different implementations over the last few years.

  • None of the RISC-V support pull requests apply in a straightforward way to the stable release of the crate that is currently available (0.16.20).  That release is roughly three years old.

  • Applying a patch to a crate in the kuksa-databroker recipe is workable with careful setting of the patchdir option in SRC_URI.

  • cargo has some provision for configuring a different version and/or source of a crate with its own patch directive in Cargo.toml.  Any changes seem likely to require also patching Cargo.lock to match.

It is likely that a fix will be either:

  1. Working up a set of patches on top of ring 0.16.20 that get one of the RISC-V pull request patches to usefully apply.

  2. Forcing the use of either the 0.17 alpha version of ring from crates.io, or an explicit clone of the github repo, then patching the RISC-V support from the latest pull request on top.

Environment

None

Activity

Walt Miner 
February 9, 2024 at 4:50 PM

Close QQ M3

Scott Murray 
December 21, 2023 at 9:38 PM

This is currently resolved for master / Quillback with the upgrade to KUKSA.val 0.4.2 plus a patch to avoid needing Rust 1.70.  It has been decided that we do not need to worry about enabling RISC-V builds for Pike.

Scott Murray 
October 10, 2023 at 8:39 PM

An update, the ring crate recently finally started releasing non-alpha versions of the 0.17 branch (now up to 0.17.3) that do include a merge of the latest RISC-V support PR.  It is not immediately obvious to me if attempting to override the version used by dependents in the high level Cargo.toml will work with respect to compatibility, so that will be an experiment that may need to be attempted.  The 4 crates that pull it in use the Cargo "^0.16.x" dependency syntax, so a simple "cargo update" of the databroker's Cargo.lock will not pick up 0.17.x, sadly.

Scott Murray 
September 14, 2023 at 6:40 PM

I brought this up on the KUKSA.val call, and they are aware of the issue.  However, they see the same problem with respect to lack of a solution from upstream as I do.

Fixed

Details

Assignee

Reporter

Fix versions

Labels

Contract ID

Components

Priority

Created August 23, 2023 at 7:12 PM
Updated February 9, 2024 at 4:50 PM
Resolved December 21, 2023 at 9:38 PM