mirror of
https://github.com/librespot-org/librespot.git
synced 2026-04-27 08:15:50 +03:00
[GH-ISSUE #1460] Improving MIPS and MIPSEL support (regarding AtomicU64 and Rust Version) #656
Labels
No labels
A-Alsa
SpotifyAPI
Tokio 1.0
audio
bug
can't reproduce
compilation
dependencies
duplicate
enhancement
good first issue
help wanted
high priority
imported
imported
invalid
new api
pull-request
question
reverse engineering
wiki
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set.
Reference
starred/librespot#656
Loading…
Add table
Add a link
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?
Originally created by @humaita-github on GitHub (Jan 28, 2025).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/1460
Hi,
up to including version 0.6. libresport can be compiled for MIPS and MIPSEL targets (to be more precise: mips-unknown-linux-musl and mipsel-unknown-linux-musl). This is useful for routers running OpenWRT, since many of them are based on these targets.
However, there are 2 issues that make it difficult to compile:
1) AtomicU64: MIPS and MIPSEL [and PowerPC (?)] don't support this, since they are 32 bit. However, there is a crate that provides shims for these platforms. When it detects it is running on unsupported platforms, it fallbacks to the shim implementation, using crossbeam Mutex. For supported platforms, there should be no change.
This can easily be implemented by changing the 1st line in
./playback/src/mixer/softmixer.rsfromuse std::sync::atomic::{AtomicU64, Ordering};to
use atomic_shim::AtomicU64;use std::sync::atomic::{Ordering};2) Rust Version: librespot v0.6. defaults to Rust version 1.75. However, in this version both MIPS and MIPSEL were moved to Tier 3. librespot v0.6 still builds fine with Rust version 1.74 -- so I suggest sticking to this version for a bit longer. I know, sounds like a big decision, but this will keep librespot viable for OpenWRT routers for a longer period of time.
This can easily be implemented by changing the 4th line in
./Cargo.tomlfromrust-version = "1.75"to
rust-version = "1.74"FYI: There is one more thing: OpenSSL headers are missing for MIPS, but this is currently being fixed somewhere else, see
https://github.com/aws/aws-lc/pull/2143
I didn't create a patch or similar since only 2 lines of code need to be changed (and since I don't really know the proper way of doing this).
@photovoltex commented on GitHub (Jan 28, 2025):
Feel free to open a PR with these changes. Sounds like nothing major and it seems somewhere
crossbeam-utilsis already in use, so it might not make a big difference as dependency.We recently bumped the MSRV to
1.81because of some dependency and an CI tools requirements. Which means that downgrading would come with some rollbacks of crate versions and a different fix for our CI. Does rust-version> 1.74block compiling all together, or what exactly is the current state of things there?@roderickvd commented on GitHub (Jan 28, 2025):
First of all thanks for opening my eyes to who and why is using
librespoton MIPS 😆Just to throw it out there, in CamilaDSP style we could also introduce a
pub type ProcessingFormatthat could be an alias to either 32 or 64 bit.@humaita-github commented on GitHub (Jan 28, 2025):
Hi @photovoltex , hi @roderickvd ,
thank you for the quick reply.
> Feel free to open a PR with these changes.
Will do.
> Does rust-version > 1.74 block compiling all together, or what exactly is the current state of things there?
AFAIK it blocks compiling all together (at least I haven't found a way to compile a Tier 3 rust target).
> CamilaDSP style we could also introduce a
pub type ProcessingFormatthat could be an alias to either 32 or 64 bit.I am open for that (but I wouldn't know hot to do something like that myself.
@photovoltex commented on GitHub (Jan 29, 2025):
Ugh, what a bummer. Well I did a look into the work that needs to be done:
1.75is pretty straight forward, by just reverting the related commitcargo-hackrequired1.811.75is the actual problemzbus@4was added, which requires1.75zbus@3@starypatyk commented on GitHub (Jan 29, 2025):
FYI - I suggested to remove MIPS target from the Docker image used to cross-compile at #1299. At that time I had issues even with 1.73.
@photovoltex commented on GitHub (Jan 31, 2025):
Wouldn't that mean
0.5also had problems to compile under MIPS? Which was the last version that did compile under MIPS @humaita-github?@humaita-github commented on GitHub (Jan 31, 2025):
Hi, yes, version
0.5has the same problem. I just used to patch it locally on my machine, withsed -i '1d' ./playback/src/mixer/softmixer.rssed -i '1s/^/use atomic_shim::AtomicU64;\nuse std::sync::atomic::{Ordering};\n/' ./playback/src/mixer/softmixer.rsecho -e '\n[dependencies.atomic-shim]\natomic-shim = "*"\n' >> playback/Cargo.tomlAnd this is more or less what I submitted as a PR 3 days ago.
Previous versions (e.g.
0.42) have the same issue. I think AtomicU64 was introduced with commitfe2d5ca7c654cd5981969ae880ccd69e6d1066d3in 2021 -- before I started using librespot.@photovoltex commented on GitHub (Feb 1, 2025):
I'm referring to the rust-version downgrade that you suggested so that we could compile for MIPS again. If it's, as @starypatyk pointed out, and even
1.73will not compile, I would see this as difficult problem to solve.@humaita-github commented on GitHub (Feb 1, 2025):
Hi, I have no issues compiling versions
0.42and0.50with rust1.74on MIPS and MIPSEL. And as mentioned already, version0.60compiles fine with rust1.74even if it requires1.75, you can just patch the Cargo.toml` file:sed -i 's/rust-version = \"1.75\"/rust-version = \"1.74\"/' Cargo.tomlCompiling version
0.60for MIPS is a bit more tricky, since openssl is missing a the MIPS headers. For now you can fix it manually, and this has already been fixed for upcoming versions, see the link in my first message.@humaita-github commented on GitHub (Feb 13, 2025):
Hi, quick update: newer rust versions also work with Tier 3 targets, its just a bit of a pain to make it work, since you basically need to compile the complete toolchain by yourself. The OpenWrt SDK does this anyway, so it shouldn't be a problem using recent Rust versions after all.
I was able to compile for 30+ targets/architectures, check out https://github.com/humaita-github/librespot-openwrt-ipk
@photovoltex commented on GitHub (Feb 13, 2025):
Does this mean after merging the
portable-atomicPR, this can be seen as completed/resolved?@humaita-github commented on GitHub (Feb 13, 2025):
Yes, thank you!