Buildin on RISC-V #762
Labels
No labels
action
check-aws
action
discussion-needed
action
for-external-contributors
action
for-newcomers
action
more-info-needed
action
need-funding
action
triage-required
kind
correctness
kind
ideas
kind
improvement
kind
performance
kind
testing
kind
usability
kind
wrong-behavior
prio
critical
prio
low
scope
admin-api
scope
background-healing
scope
build
scope
documentation
scope
k8s
scope
layout
scope
metadata
scope
ops
scope
rpc
scope
s3-api
scope
security
scope
telemetry
No milestone
No project
No assignees
2 participants
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference: Deuxfleurs/garage#762
Loading…
Reference in a new issue
No description provided.
Delete branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Hi,
I’m one of the lucky ones to have a RISC-V server by Scaleway. I tried to compile garage for it (directly on master), and ran into an issue regarding
libsodium-sys
compilation:By poking around, I found this PR that fixes the issue, but on a abandoned crate. The maintained version of this crate seems to be used for compiling
libsodium
but notlibsodium-sys
, forcing to play around inside Cargo cache to fix the issue.I haven’t found a proper way to build this, hence the opening of this issue. Is there a way to update this dependency properly?
Related: #127
At some point we might be interested in porting the code to
ssb-handshake
+ssb-boxstream
which are implemented using Rust crypto primitives.Note that at this point, SSB packages from sunrise-choir seem to have less activity than those from kuska-ssb (the one we are using).
In the meantime, have you tried compiling just the libsodium-sys crate on RISC-V using the patch you found? If you're able to port the patch to the maintained version we might be able to do PRs on kuska-sodiumoxide and kuska-handhake to be able to integrate those changes with Garage.
I was able to compile it inside
libsodium-sys
via the patch referenced. What I really don’t understand is why this outdated library is still used when compilingkuska-sodiumoxide
. Shouldn’t it use the version oflibsodium-sys
shipped withkuska-sodiumoxide
?Anyway, I was able to adapt the patch and compile
kuska-sodiumoxide
on RISC-V (see attachment) but this does not seem to be the version used within garage so…As I understand it:
kuska-handshake has this line in their
cargo.toml
:So they will import the package kuska-sodiumoxide from crates.io
The source for kuska-sodium is in this repo, and in their
cargo.toml
they have this line:This means that if you clone the repo of kuska-sodiumoxide and do a
cargo build
, it will use the libsodium-sys that is in that repo from the libsodium-sys folder. However, once that crate is published on crates.io, and it is imported in other apps, it will use the officiallibsodium-sys
crate, version 0.2.4 or newer. Garage is locked to the current version which is0.2.7
on crates.io, so that is the one that is used when building Garage.In conclusion, to fix RISC-V, you need to patch the build script in the upstream libsodium-sys repo (which is archived, so good luck with that) and get them to publish a new version on crates.io which we can then use in Garage by updating our lock file.
Since upstream libsodium-sys is probably not going to update anything, other options include 1/ publishing a forked libsodium-sys on crates.io, possibly from the kuska-ssb sodiumoxide repo, or 2/ rewriting the code to not use libsodium at all.
I agree that depending on an unmaintained crate is a big problem and I might put some energy in fixing this situation in the comming weeks.
Note that this crate seems to be a maintaned version of libsodium-sys : https://crates.io/crates/libsodium-sys-stable.
We might be able to convince the kuska people to migrate kuska-sodiumoxide to that binding instead of the deprecated one.
Made a PR on kuska-sodiumoxide : https://github.com/Kuska-ssb/sodiumoxide/pull/1