starred/librespot
1
0
Fork 0
mirror of https://github.com/librespot-org/librespot.git synced 2026-04-27 08:15:50 +03:00
Code Issues 95 Projects Releases 10 Packages Wiki Activity

[GH-ISSUE #328] Fails to build correctly with arm-unknown-linux-musleabihf target and rust > v1.21 #216

New issue
Closed
opened 2026-02-27 19:29:27 +03:00 by kerem · 16 comments
kerem commented 2026-02-27 19:29:27 +03:00
Owner
Copy link

Originally created by @michaelherger on GitHub (Apr 9, 2019).
Original GitHub issue: https://github.com/librespot-org/librespot/issues/328

I used to successfully compile librespot on a Pi3 with the "arm-unknown-linux-musleabihf" target. Up until a few months ago this was fine. Then the requirement for some rust later than 1.21 was introduced. And I never succeeded building for that target again. As soon as I use a more recent rust environment the binary would fail to run. It's not even considered a statically linked binary any more:

$ file target/arm-unknown-linux-musleabihf/debug/librespot
target/arm-unknown-linux-musleabihf/debug/librespot: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /usr, BuildID[sha1]=dfa1ae4ddd017f8ad9b084905e2eedad079ecf8d, not stripped

Trying to run it I'd get the rather generic "file or folder not found" message:

$ target/arm-unknown-linux-musleabihf/debug/librespot
bash: target/arm-unknown-linux-musleabihf/debug/librespot: Datei oder Verzeichnis nicht gefunden

What's wrong with this file? I noticed that during the build I would at some point get the following message:

warning: dropping unsupported crate type `cdylib` for target `arm-unknown-linux-musleabihf`

Could this be the reason for the failure?

FWIW: I'm successfully linking against musl on i386 and x86_64.

Originally created by @michaelherger on GitHub (Apr 9, 2019). Original GitHub issue: https://github.com/librespot-org/librespot/issues/328 I used to successfully compile librespot on a Pi3 with the "arm-unknown-linux-musleabihf" target. Up until a few months ago this was fine. Then the requirement for some rust later than 1.21 was introduced. And I never succeeded building for that target again. As soon as I use a more recent rust environment the binary would fail to run. It's not even considered a statically linked binary any more: ``` $ file target/arm-unknown-linux-musleabihf/debug/librespot target/arm-unknown-linux-musleabihf/debug/librespot: ELF 32-bit LSB executable, ARM, EABI5 version 1 (SYSV), dynamically linked, interpreter /usr, BuildID[sha1]=dfa1ae4ddd017f8ad9b084905e2eedad079ecf8d, not stripped ``` Trying to run it I'd get the rather generic "file or folder not found" message: ``` $ target/arm-unknown-linux-musleabihf/debug/librespot bash: target/arm-unknown-linux-musleabihf/debug/librespot: Datei oder Verzeichnis nicht gefunden ``` What's wrong with this file? I noticed that during the build I would at some point get the following message: ``` warning: dropping unsupported crate type `cdylib` for target `arm-unknown-linux-musleabihf` ``` Could this be the reason for the failure? FWIW: I'm successfully linking against musl on i386 and x86_64.
kerem 2026-02-27 19:29:27 +03:00
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@CodeCutterUK commented on GitHub (Apr 10, 2019):

I'm building on 1.31.1 without issue, however I had been on commit daeeeaa122
So I suspect it isn't the version. Equally I'm building as arm-unknown-linux-gnueabihf

Moving to master, currently 14721f45fe , seems to break things......I'm yet to go through and find which commit breaks it, but initial debugging suggests that updating the dependant packages may have introduced a package/version that doesn't build on ARM correctly.

<!-- gh-comment-id:481819662 --> @CodeCutterUK commented on GitHub (Apr 10, 2019): I'm building on 1.31.1 without issue, however I had been on commit daeeeaa122fc2d71edf11e562e23038db4210b39 So I suspect it isn't the version. Equally I'm building as `arm-unknown-linux-gnueabihf` Moving to master, currently 14721f45fe7e3e5427abdfdedca6ed1ec8948d80 , seems to break things......I'm yet to go through and find which commit breaks it, but initial debugging suggests that updating the dependant packages may have introduced a package/version that doesn't build on ARM correctly.
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@michaelherger commented on GitHub (Apr 10, 2019):

See my last paragraph: musl linking does work on i386 and x86_64 for me, too. As well as arm-unknown-linux-gnueabihf and half a dozen other platforms. It's really only muslabihf that's causing problems. And this used to work until Rust 1.21. It still works for a simple "Hello World" and Rust 1.33. I guess it's some crate librespot is using which is no longer supported. But how could I figure out which one it is?

<!-- gh-comment-id:481845770 --> @michaelherger commented on GitHub (Apr 10, 2019): See my last paragraph: musl linking does work on i386 and x86_64 for me, too. As well as arm-unknown-linux-gnueabihf and half a dozen other platforms. It's really only muslabihf that's causing problems. And this used to work until Rust 1.21. It still works for a simple "Hello World" and Rust 1.33. I guess it's some crate librespot is using which is no longer supported. But how could I figure out which one it is?
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@ashthespy commented on GitHub (Apr 10, 2019):

While compiling, try running cargo in verbose mode with --verbose to help debug if you haven't already.

<!-- gh-comment-id:481878786 --> @ashthespy commented on GitHub (Apr 10, 2019): While compiling, try running cargo in verbose mode with `--verbose` to help debug if you haven't already.
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@CodeCutterUK commented on GitHub (Apr 12, 2019):

Just a quick update - switching to armv7-unknown-linux-gnueabihf from arm-unknown-linux-gnueabihffixed my issues

arm-unknown-linux-gnueabihf worked up until e9b159e9d9 I haven't dug into the detail

<!-- gh-comment-id:482512044 --> @CodeCutterUK commented on GitHub (Apr 12, 2019): Just a quick update - switching to `armv7-unknown-linux-gnueabihf` from `arm-unknown-linux-gnueabihf`fixed my issues `arm-unknown-linux-gnueabihf` worked up until e9b159e9d9990eb4674482f76a46bf53fbaa664f I haven't dug into the detail
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@sashahilton00 commented on GitHub (Apr 17, 2019):

let us know if you identify the cause of the issue - we don't really hve the resources to test cross all platforms, hence armv6 probably slipped through the net. If there is a quick fix we can look at implementing it.

<!-- gh-comment-id:483909746 --> @sashahilton00 commented on GitHub (Apr 17, 2019): let us know if you identify the cause of the issue - we don't really hve the resources to test cross all platforms, hence armv6 probably slipped through the net. If there is a quick fix we can look at implementing it.
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@PKizzle commented on GitHub (May 13, 2019):

The warning dropping unsupported crate type cdylib for target arm-unknown-linux-musleabihf is caused by lewton v0.9.4

<!-- gh-comment-id:491950596 --> @PKizzle commented on GitHub (May 13, 2019): The warning `dropping unsupported crate type cdylib for target arm-unknown-linux-musleabihf` is caused by lewton v0.9.4
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@PKizzle commented on GitHub (May 13, 2019):

I was able to remove the warning by adding -C target-feature=-crt-static to the rustc command

<!-- gh-comment-id:491980676 --> @PKizzle commented on GitHub (May 13, 2019): I was able to remove the warning by adding `-C target-feature=-crt-static` to the rustc command
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@PKizzle commented on GitHub (May 14, 2019):

Using -C target-feature=-crt-static -C link-arg=-lm -C link-arg=-ldl -C link-arg=-lpthread
I am able to successfully build, but receive the following error message when trying to execute:

thread '<unnamed>' panicked at 'failed to allocate an alternative stack', src/libstd/sys/unix/stack_overflow.rs:136:13
stack backtrace:
   0: <unknown>
   1: <unknown>
   2: <unknown>
   3: <unknown>
   4: <unknown>
   5: <unknown>
   6: <unknown>
   7: main
   8: __libc_start_main
fatal runtime error: failed to initiate panic, error 9
Aborted (core dumped)

So it seems to be an internal rust issue...

<!-- gh-comment-id:492358439 --> @PKizzle commented on GitHub (May 14, 2019): Using `-C target-feature=-crt-static -C link-arg=-lm -C link-arg=-ldl -C link-arg=-lpthread` I am able to successfully build, but receive the following error message when trying to execute: ``` thread '<unnamed>' panicked at 'failed to allocate an alternative stack', src/libstd/sys/unix/stack_overflow.rs:136:13 stack backtrace: 0: <unknown> 1: <unknown> 2: <unknown> 3: <unknown> 4: <unknown> 5: <unknown> 6: <unknown> 7: main 8: __libc_start_main fatal runtime error: failed to initiate panic, error 9 Aborted (core dumped) ``` So it seems to be an internal rust issue...
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@ashthespy commented on GitHub (Mar 20, 2020):

Is this still an issue with the current version?
@michaelherger @PKizzle

<!-- gh-comment-id:601942934 --> @ashthespy commented on GitHub (Mar 20, 2020): Is this still an issue with the current version? @michaelherger @PKizzle
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@PKizzle commented on GitHub (Mar 20, 2020):

No, I was able to compile successfully with newer versions of librespot. Just one thing I noticed: I have to specify --no-default-features --features rodio-backend for the compilation to succeed. The default build option somehow don’t work for me.

<!-- gh-comment-id:601946890 --> @PKizzle commented on GitHub (Mar 20, 2020): No, I was able to compile successfully with newer versions of librespot. Just one thing I noticed: I have to specify `--no-default-features --features rodio-backend` for the compilation to succeed. The default build option somehow don’t work for me.
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@ashthespy commented on GitHub (Mar 21, 2020):

That is interesting, default should be libmdns + rodio, so looks like libmdns isn't playing well with your target?

<!-- gh-comment-id:602018610 --> @ashthespy commented on GitHub (Mar 21, 2020): That is interesting, `default` should be `libmdns` + `rodio`, so looks like `libmdns` isn't playing well with your target?
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@PKizzle commented on GitHub (Apr 13, 2020):

I tried again and with updated dependencies the whole project can be successfully compiled for arm-unknown-linux-musleabihf with the deault features (including libmdns). The issue may hereby be closed.
Used compilation arguments:

RUSTFLAGS="-C link-args=-Wl,-rpath-link,/lib -C target-feature=-crt-static" PKG_CONFIG_PATH=/usr/lib/pkgconfig PKG_CONFIG_ALLOW_CROSS=1 cargo build --release
<!-- gh-comment-id:613002932 --> @PKizzle commented on GitHub (Apr 13, 2020): I tried again and with updated dependencies the whole project can be successfully compiled for `arm-unknown-linux-musleabihf` with the deault features (including libmdns). The issue may hereby be closed. Used compilation arguments: ``` RUSTFLAGS="-C link-args=-Wl,-rpath-link,/lib -C target-feature=-crt-static" PKG_CONFIG_PATH=/usr/lib/pkgconfig PKG_CONFIG_ALLOW_CROSS=1 cargo build --release ```
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@ashthespy commented on GitHub (Apr 13, 2020):

@PKizzle Could you add an entry to the wiki if you think this needs some special hints to get compiled?

<!-- gh-comment-id:613052336 --> @ashthespy commented on GitHub (Apr 13, 2020): @PKizzle Could you add an entry to the [wiki](https://github.com/librespot-org/librespot/wiki/Cross-compiling) if you think this needs some special hints to get compiled?
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@PKizzle commented on GitHub (May 7, 2020):

@ashthespy I added it to the wiki. Could you please review the changes?

<!-- gh-comment-id:625358682 --> @PKizzle commented on GitHub (May 7, 2020): @ashthespy I added it to the wiki. Could you please review the changes?
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@ashthespy commented on GitHub (May 7, 2020):

@PKizzle Thanks, if you could add a note about musleabihf as well it would be superb..
In the meantime, will mark this as fixed.

<!-- gh-comment-id:625375770 --> @ashthespy commented on GitHub (May 7, 2020): @PKizzle Thanks, if you could add a note about `musleabihf` as well it would be superb.. In the meantime, will mark this as fixed.
kerem commented 2026-02-27 19:29:28 +03:00
Author
Owner
Copy link

@PKizzle commented on GitHub (May 7, 2020):

I added a note which target is meant by armv6

<!-- gh-comment-id:625436101 --> @PKizzle commented on GitHub (May 7, 2020): I added a note which target is meant by armv6
Sign in to join this conversation.
No Branch/Tag specified
Branches Tags
dev
v0.8.0
v0.7.1
v0.7.0
v0.6.0
v0.5.0
v0.4.2
v0.4.1
v0.4.0
v0.3.1
v0.3.0
v0.2.0
v0.1.6
v0.1.5
v0.1.3
v0.1.2
v0.1.1
v0.1.0
Labels
Clear 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

Mirrored from GitHub Pull Request

  
question

   
reverse engineering

   
wiki

   
wontfix
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
Milestone
Clear milestone
No items
No milestone
Projects
Clear projects
No items
No project
Assignees
Clear assignees
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#216
No description provided.