While waiting for the next SDK to be available for 4.6.x to be able to try some new rust version goodness, I figured out I could use community OBS builds which should work just the same. I have a couple of problems though.
The packages I’m trying to build are librespot and wl-clipboard-rs.
N.B: Both packages build on intel without errors!
The first one (librespot) is a modified version of wdehoog’s version that drops most of the rust version patches and uses a fresher vendor archive.
The error:
= note: /usr/bin/ld: cannot find -lasound: No such file or directory
/usr/bin/ld: cannot find -lpulse-simple: No such file or directory
/usr/bin/ld: cannot find -lpulse: No such file or directory
/usr/bin/ld: cannot find -lpulse: No such file or directory
collect2: error: ld returned 1 exit status
previously -L has "/usr/lib/rustlib/i686-unknown-linux-gnu/lib" even on the ARM targets…
The second one (wl-clipboard-rs) has dependencies on cargo-packaging and cargo-auditable.
Both packages are siblings and are failing one way or another to complete the build on non-Intel targets.
The "failure"s are just build being stuck at some (random) phase. I have tried to remove the --release from cargo build --offline --release and I noticed some builds (e.g. 32-bit) go a bit further. But the time they are locked is not consistent, meaning that I do not spot a pattern (30’ seconds? 60’ seconds?)
They are just killed after 1800 seconds.
And again, they ALL pass with an Intel target.
So to recap: library errors and builds stuck with cargo build only on ARM…
L.E. None of the software above would have build without deep changes to accommodate the old version of rust before. The fact that the builds pass on Intel are a clear win 
, and they may pass on device too, since both errors seem to be VM related
3 Likes
This thread might be having some answers for both… trying now Wrong linker for Rust cross-compiling
Update: the SB2 fixes did help with the librespot linker errors.
librespot package
Now the best librespot build I’ve come to is from librespot-git and it’s output in e.g. Index of /obs/home:/b100dian:/rust-packages/sailfish_latest_aarch64/aarch64 is librespot-0.4.2+master.20240716132332.6b78169-1.17.1.jolla.aarch64.rpm which is from 16-Jul-2024 (or a later one) not the 15-Jul one which is from librespot project.
The main novelty of the -git build is defaultuser instead of nemo and pulseaudio volume control.
For the build locking up, changes like these didn’t help - the librespot package was just built by accident / multiple tries and the cargo-packaging/cargo-auditable/wl-clipboard-rs do not build yet, still investigating.
One more update: there is actually an SDK with rust 1.75, and that is SailfishOS-4.6.0.11EA today.
Building one of the above packages clearly showed that the build was multi-threaded, so I remembered that sailfishos-browser was doing the -j1 thing (via @flypig’s blog posts) and lo and behold, adding -j1 (sometimes disguised as %define _smp_mflags -j1 if you’re using %{cargo_build} macro from cargo packaging) does finish all of the [librespot|cargo-packaging|cargo-auditable|wl-clipboard-rs] packages build on OBS (though in a very large amount of time). -j1 is also used in Whisperfish so…
Anyway, now librespot is probably submittable to chum. Next thing I need to figure out is what went wrong with wl-clipboard-rs because the aarch64 build outputs an i386 ELF 
…
2 Likes
The last bit of info is that wl-cliboard-rs’s %{cargo_install} macro was rebuilding for i386. This was easily fixed with --target %{SB2_TARGET}.
I’ll try to recap what I needed to do for building cargo/rust software on OBS:
- For each package you need to clone it locally and run
cargo vendor --locked which produces a vendor/ folder and an output to add to cargo_config
- Zip vendor (or tar) and create a cargo_config file with the output from the cargo vendor command. See for example cargo-packaging in OBS
- Add
vendor.tar.xz and cargo_config as Source1, Source2 etc. in the spec file and unpack the former and copy the latter in the %prep step, e.g. cargo-packaging.spec
- Serialize the build… hopefully this will not be needed forever. If the spec uses
cargo build --offline --release add -j1. If the spec uses %{cargo_build} then %define _smp_mflags -j1 before it.
- Apply advice from the Wrong linker for Rust cross-compiling - #4 by R1tschY thread (which is also seen in xulrunner spec). I have done it like this for example.
- If your package depends on cargo-packaging and uses
%{cargo_install} append --target %{SB2_TARGET} to that macro invocation otherwise you’ll get an intel build.
Hope this helps somebody in the future;)
5 Likes
If anyone knows how to solve the bindgen error on armv7hl on OBS I’d be happy to hear…
error: failed to run custom build command for `aws-lc-sys v0.22.0`
Failure invoking external bindgen! External bindgen command failed.
For Show home:b100dian:rust-packages / librespot-git - SailfishOS Open Build Service
1 Like
Some “progress”: cargo vendor without locked or offline flags, after adding
aws-lc-rs = { version = "1", features = ["bindgen"] }
to the dependencies of librespot (in Cargo.toml).
This is because according to Platform Support - AWS Libcrypto for Rust User Guide, only aarch64-unknown-linux-gnu and x86_64-unknown-linux-gnu from what we use are pre-generated bindings, and arm-unknown-linux-gnueabihf is not.
The change in the toml file also required creating a patch after that cargo vendor, like git diff -u > ../rpm/001-aws_lc_rs-feature-bindgen.patch so it is applied after checking out the submodule (plus, a change from rpm %setup to %autosetup)
Now, the error changes in that it needs libclang.so.X.0.Y. While I did add clang-libs to BuildRequires, it may be an error that rust is again outside the target while searching for libs ? Also, with this change, the intel target doesn’t build anymore ( fatal error: 'stddef.h' file not found - probably requires more deps, but again, the SB2 virtualised platforms really struggle to find the right tools/libs. ).
Maybe this “aws-lc-rs” is not actually needed, and can be removed, but it is a transient dependency, hard to tell at this hour. maybe some other time.
1 Like
Getting rid of aws-ls-rs (actually aws-ls-sys is the culprit) is something rustaceans don’t have right now Completely disable downstream feature (aws-lc-sys) - help - The Rust Programming Language Forum …
1 Like
One of the more complex Rust projects, I think, is Whisperfish. We got it compiling quite well with @rubdos and we’re getting ready to merge that work.
I also tried to make ripgrep compile (extending the inspiration above), but I ran into some C issues, oddly enough. Well, it’s at least updated on Openrepos now.
Half related, Fish shell 3.7.1 is also now in Chum. Version 4.0, now in beta 1, is rewritten in Rust, but I couldn’t quite get that working yet. I’ll be poking that around every now and then.
3 Likes
Just to add that there is something called cargo-vendor-filterer which can be used to avoid things like windows, or archs that are not required.
Will probably help to keep the vendor.tar small.
cargo vendor-filterer --platform=armv7-unknown-linux-gnueabihf --format=dir ./vendor-filtered-armv7
cargo vendor-filterer --platform=aarch64-unknown-linux-gnu --format=dir ./vendor-filtered-aarch64
cargo vendor-filterer --platform=i686-unknown-linux-gnu --format=dir ./vendor-filtered-ix86
# ... or all in one:
cargo vendor-filterer --platform=armv7-unknown-linux-gnueabihf --platform=aarch64-unknown-linux-gnu --platform=i686-unknown-linux-gnu --format=dir ./vendor-filtered
It can also output a vendor.tar directly, using --prefix=vendor --format=tar
Unfortunately it doesn’t seem to offer a way to add --locked or I haven’t found out how.
2 Likes