SegFault on RPi1

[cthulu]

Tried x-compiling for RPi1, using docker run -v /tmp/librespot-build:/build librespot-cross cargo build --release --target arm-unknown-linux-gnueabi --no-default-features --features alsa-backend with Alsa backend.

I've tried playing from different sources but I always get a SegFault

DEBUG:librespot::spirc: kMessageTypeNotify "MMP" a7688466272188c8a7008257303bf01d8a4f355d 106 1491461811965
TRACE:librespot::audio_file: chunk 0 / 44 complete
TRACE:librespot::audio_file: requesting chunk 1
TRACE:librespot::audio_file: requesting chunk 43
TRACE:librespot::audio_file: chunk 43 / 44 complete
TRACE:librespot::audio_file: requesting chunk 1
TRACE:librespot::audio_file: chunk 1 / 44 complete
TRACE:librespot::audio_file: requesting chunk 2
Segmentation fault

I'm not even sure if it's supposed to be working or not :)

[plietar]

Could you run it in gdb please ?

$ gdb --args target/release/librespot -n xxx -u xxx -p xxx
[ ... ]
(gdb) run
[ wait for it to crash ]
(gdb) backtrace

[cthulu]

Sure, here's the output:

DEBUG:librespot::spirc: kMessageTypeNotify "MMP" a7688466272188c8a7008257303bf01d8a4f355d 115 1491465309675
TRACE:librespot::audio_file: chunk 15 / 37 complete
TRACE:librespot::audio_file: requesting chunk 16
TRACE:librespot::audio_file: chunk 16 / 37 complete
TRACE:librespot::audio_file: requesting chunk 17

Program received signal SIGSEGV, Segmentation fault.
[Switching to Thread 0xb67ff380 (LWP 6301)]
0xb6cdbdf0 in __sincos (x=0, sinx=0x0, cosx=0x0) at ../sysdeps/ieee754/dbl-64/s_sincos.c:42
42  ../sysdeps/ieee754/dbl-64/s_sincos.c: No such file or directory.
(gdb) backtrace
#0  0xb6cdbdf0 in __sincos (x=0, sinx=0x0, cosx=0x0) at ../sysdeps/ieee754/dbl-64/s_sincos.c:42
#1  0x7f89ecc0 in mdct_init ()
Cannot access memory at address 0xf8
(gdb) 

Not sure it helps as it's the release version.

[cthulu]

Seems like using this release works for RPi1: https://github.com/herrernst/librespot/releases

[herrernst]

I am quite surprised that it even starts up, assuming you are using Raspbian (are you?). Raspberry Pi 1 has an ARMv6 CPU. There are two Debian ARM ports (which are used in the Docker container to cross compile): the older, "slower" one (armel), and the newer, "faster" one (armhf). Unfortunately, the latter, armhf, requires an ARMv7 CPU (which RPi 2 and 3 have, but not the first one). This is why Raspbian is built specifically as armhf v6. You are cross-compiling to armel (=gnueabi) and producing a binary that is not compatible with your userland (unless you are using a very ancient Raspbian). Unfortunately, cross-compiling to armhf won't help either, because it produces a binary incompatible with your CPU.

[cthulu]

Yeah I'm on Raspbian Jesse. I guess I just got lucky when it started up (and segfaulted :)? Anyway, glad it worked with your release :)

[balbuze]

The only way I found to produce a working armv6 librespot is to compile on armv6 (RPI B). Is there a quickest way?

[herrernst]

@balbuze You can cross-compile like "normally", but with the Raspberry Pi tools (compiler etc.). I let travis do it with these script: https://github.com/herrernst/librespot/blob/871e9e89821f75146277bc736103bbfb5c1a74b1/.travis.yml#L18

[balbuze]

thanks a lot ! To be more precise, I need to compile three different version arm (for rpi 0, B) armhf (rpi 2,3, and other armv7) i686 ( 32bits x86) I want to cross compile on a ubuntu 64. With the default setting, only armhf generated is usable. I'm compiling with your travis.yml, as I understand it should be ok for arm version. Wait... Do you how to generate i686 code ? ( not 64bits) ?

[balbuze]

I realize I don't know how to use your script... I place it a the root of librespot folder remplacing the existing one. And start cross compiling. Now but didn't produce what expected...

[cthulu]

@herrernst the build works on RPi 1 but now I'm a bit stuck at trying to get it compiled and running on my Synolgy DS 214:

$ uname -a
Linux valinor 2.6.32.12 #8451 Wed Jan 4 00:36:00 CST 2017 armv5tel GNU/Linux synology_88f6282_213

Of the 3 builds (yours, and two provided by the Docker container) only the arm-unknown-linux-gnueabi is able to start on the target.

Unfortunately I'm facing this:

$ ./librespot 
./librespot: /lib/libc.so.6: version `GLIBC_2.18' not found (required by ./librespot)
./librespot: /lib/libc.so.6: version `GLIBC_2.17' not found (required by ./librespot)

So it looks like the glibc Rust is expecting is at least 2.17. Looking at the toolchain for my Synology NAS model https://sourceforge.net/projects/dsgpl/files/DSM%206.1%20Tool%20Chains/Marvell%2088F628x%20Linux%202.6.32/ it looks like they are at GLIBC 2.15. I am not really good with x-compiling and Rust/Cargo, but is it doable to get a binary which is linked to 2.15?

By using cargo tree it looks like lot of libraries are linking libc which isn't too great. I actually don't need any audio output, the idea is to send the output of librespot to pipe and ffmpeg it so my squeezebox can play it :)

[herrernst]

@cthulu First thing I would try is to adopt the Dockerfile to use an older Debian to build the armel version, i. e. change the line "FROM debian:stretch" in to debian:jessie or even older (look up which Debian has an older libc than 2.15). But I'm not sure if it will work; maybe you also have to remove the armhf stuff in the Dockerfile.

Also, if I remember correctly, @joerg-krause has done some stuff with armv5te, maybe he can help.

[cthulu]

That was my first thought, I went to jessie but that wasn't good enough. I thought for the x-compile the actual libc isn't the one used in Debian but in the toolchain (and afaik the rust installer just pulls the libc dependency from cargo.io) I will try wheezy that seems to be the version with 2.13 libc. Edit: wheezy is not supported by embedian -- meaning, they don't have the x-compile packages :(

[cthulu]

Synology provides the cross compile toolchain, just unsure how to use it to x-compile things inside a docker container.

[joerg-krause]

@herrernst Sorry, I cannot help with anything related to docker. Furthermore, I am using a musl-based toolchain...

[cthulu]

@joerg-krause do you use toolchain to compile rustc- related architecture? I have toolchain from Synology, and I wanna use Docker (I'm on Mac and wanna compile on Debian). I can do it all in interactive terminal, just because it's simpler. The toolchain from them has gcc, ld etc so I thought if I can use rustc afterwards to compile to my architecture using my toolchain, it should be working. I'm not sure how to get to use the libc (2.15) instead of the 2.17/2.18.

[joerg-krause]

I am using rust-cross-libs to cross-compile the rust libraries for my ARMv5 target. Of course, you need a cross-compiler to do so. I'm using Buildroot to build a musl-based cross-toolchain and also to build the necessary dependencies like Tremor, alsa-lib, etc.

You could use Buildroot, to build your own toolchain, too. As a Buildroot version only supports the most recents version of the packages, you would need some older version of Buildroot to build a glibc 2.15 based toolchain.

[superlupo12]

@cthulu Does your Synology thing even support audio output? And if yes, how? Does it have ALSA? Or can it be added? BTW, I would suggest closing this issue now that it has drifted away (and the basic issue is invalid).

[cthulu]

@superlupo12 yeah let's close it (I don't have permission to do that though).

Synology doesn't have audio output, but I'm running Logitech Media Server on it and I have a Squeezbox Radio. The thought was, to actually pipe the raw output from librespot to vlc and transcode it to mp3 stream, and on then I can tune to that MP3 stream on my Squeezbox. Or, I can just use RPi1 (which I already have a working binary for) and just use that in combination with another external speaker...

[superlupo12]

@cthulu Out of interest I've cross-compiled a binary (without any audio backend) with the Synology tools you've provided, maybe it works with the pipe backend: http://s000.tinyupload.com/index.php?file_id=06713955002183772452

[cthulu]

I've tried it but I only get Illegal instruction when I try to run it. Not sure what actually is going wrong there... I've of course added +x on the file

$ ./librespot.armv5tel 
Illegal instruction

[dtcooper]

@plietar + @herrernst + @cthulu , I have builds (and an associated Dockerfile to make them) working @ https://github.com/dtcooper/raspotify

[michaelherger]

@dtcooper - this sounds very interesting. Are you saying that those hf files would run on the Pi1/0, too?

[dtcooper]

Correct, I believe they should run on both. If you confirm please let me know. I've tested on the devices mentioned on the Readme.md for the project.