Building cargo / rust software on community OBS

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 :wink:, 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 :smiley:

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;)

4 Likes