[GH-ISSUE #1460] Improving MIPS and MIPSEL support (regarding AtomicU64 and Rust Version) #656

Closed
opened 2026-02-27 19:31:47 +03:00 by kerem · 12 comments
Owner

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.rs from

use 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.toml from

rust-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).

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.rs` from `use 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.toml` from `rust-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).
kerem 2026-02-27 19:31:47 +03:00
Author
Owner

@photovoltex commented on GitHub (Jan 28, 2025):

  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.

Feel free to open a PR with these changes. Sounds like nothing major and it seems somewhere crossbeam-utils is already in use, so it might not make a big difference as dependency.

  1. 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.

We recently bumped the MSRV to 1.81 because 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.74 block compiling all together, or what exactly is the current state of things there?

<!-- gh-comment-id:2619560886 --> @photovoltex commented on GitHub (Jan 28, 2025): > 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. Feel free to open a PR with these changes. Sounds like nothing major and it seems somewhere `crossbeam-utils` is already in use, so it might not make a big difference as dependency. > 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. We recently bumped the MSRV to `1.81` because 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.74` block compiling all together, or what exactly is the current state of things there?
Author
Owner

@roderickvd commented on GitHub (Jan 28, 2025):

First of all thanks for opening my eyes to who and why is using librespot on MIPS 😆

Just to throw it out there, in CamilaDSP style we could also introduce a pub type ProcessingFormat that could be an alias to either 32 or 64 bit.

<!-- gh-comment-id:2619980292 --> @roderickvd commented on GitHub (Jan 28, 2025): First of all thanks for opening my eyes to who and why is using `librespot` on MIPS 😆 Just to throw it out there, in CamilaDSP style we could also introduce a `pub type ProcessingFormat` that could be an alias to either 32 or 64 bit.
Author
Owner

@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 ProcessingFormat that 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.

<!-- gh-comment-id:2620032100 --> @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 ProcessingFormat` that 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.
Author
Owner

@photovoltex commented on GitHub (Jan 29, 2025):

AFAIK it blocks compiling all together (at least I haven't found a way to compile a Tier 3 rust target).

Ugh, what a bummer. Well I did a look into the work that needs to be done:

  • dropping to 1.75 is pretty straight forward, by just reverting the related commit
    • the CI needs to be fixed as cargo-hack required 1.81
  • dropping to 1.75 is the actual problem
    • in #1347 zbus@4 was added, which requires 1.75
    • dropping requires the downgrade to zbus@3
      • which can't compile without any adjustments
<!-- gh-comment-id:2622857862 --> @photovoltex commented on GitHub (Jan 29, 2025): > AFAIK it blocks compiling all together (at least I haven't found a way to compile a Tier 3 rust target). Ugh, what a bummer. Well I did a look into the work that needs to be done: - dropping to `1.75` is pretty straight forward, by just reverting the related commit - the CI needs to be fixed as `cargo-hack` required `1.81` - dropping to `1.75` is the actual problem - in #1347 `zbus@4` was added, which requires `1.75` - dropping requires the downgrade to `zbus@3` - which can't compile without any adjustments
Author
Owner

@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.

<!-- gh-comment-id:2623138886 --> @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.
Author
Owner

@photovoltex commented on GitHub (Jan 31, 2025):

Wouldn't that mean 0.5 also had problems to compile under MIPS? Which was the last version that did compile under MIPS @humaita-github?

<!-- gh-comment-id:2628501718 --> @photovoltex commented on GitHub (Jan 31, 2025): Wouldn't that mean `0.5` also had problems to compile under MIPS? Which was the last version that did compile under MIPS @humaita-github?
Author
Owner

@humaita-github commented on GitHub (Jan 31, 2025):

Hi, yes, version 0.5 has the same problem. I just used to patch it locally on my machine, with

sed -i '1d' ./playback/src/mixer/softmixer.rs
sed -i '1s/^/use atomic_shim::AtomicU64;\nuse std::sync::atomic::{Ordering};\n/' ./playback/src/mixer/softmixer.rs
echo -e '\n[dependencies.atomic-shim]\natomic-shim = "*"\n' >> playback/Cargo.toml

And 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 commit fe2d5ca7c654cd5981969ae880ccd69e6d1066d3 in 2021 -- before I started using librespot.

<!-- gh-comment-id:2628555961 --> @humaita-github commented on GitHub (Jan 31, 2025): Hi, yes, version `0.5` has the same problem. I just used to patch it locally on my machine, with `sed -i '1d' ./playback/src/mixer/softmixer.rs` `sed -i '1s/^/use atomic_shim::AtomicU64;\nuse std::sync::atomic::{Ordering};\n/' ./playback/src/mixer/softmixer.rs` `echo -e '\n[dependencies.atomic-shim]\natomic-shim = "*"\n' >> playback/Cargo.toml` And 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 commit `fe2d5ca7c654cd5981969ae880ccd69e6d1066d3` in 2021 -- before I started using librespot.
Author
Owner

@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.73 will not compile, I would see this as difficult problem to solve.

<!-- gh-comment-id:2628612041 --> @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.73` will not compile, I would see this as difficult problem to solve.
Author
Owner

@humaita-github commented on GitHub (Feb 1, 2025):

Hi, I have no issues compiling versions 0.42 and 0.50 with rust 1.74 on MIPS and MIPSEL. And as mentioned already, version 0.60 compiles fine with rust 1.74 even if it requires 1.75, you can just patch the Cargo.toml` file:

sed -i 's/rust-version = \"1.75\"/rust-version = \"1.74\"/' Cargo.toml

Compiling version 0.60 for 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.

<!-- gh-comment-id:2629117317 --> @humaita-github commented on GitHub (Feb 1, 2025): Hi, I have no issues compiling versions `0.42` and `0.50` with rust `1.74` on MIPS and MIPSEL. And as mentioned already, version `0.60` compiles fine with rust `1.74` even if it requires `1.75`, you can just patch the Cargo.toml` file: `sed -i 's/rust-version = \"1.75\"/rust-version = \"1.74\"/' Cargo.toml` Compiling version `0.60` for 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.
Author
Owner

@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

<!-- gh-comment-id:2657732584 --> @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
Author
Owner

@photovoltex commented on GitHub (Feb 13, 2025):

Does this mean after merging the portable-atomic PR, this can be seen as completed/resolved?

<!-- gh-comment-id:2657797261 --> @photovoltex commented on GitHub (Feb 13, 2025): Does this mean after merging the `portable-atomic` PR, this can be seen as completed/resolved?
Author
Owner

@humaita-github commented on GitHub (Feb 13, 2025):

Yes, thank you!

<!-- gh-comment-id:2657804459 --> @humaita-github commented on GitHub (Feb 13, 2025): Yes, thank you!
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
starred/librespot#656
No description provided.