Snapclient on logitech squeezebox radio

[TotalSpaceshipguy]

So... Stupid me thought this would be an easy project !!!

This device runs on a Linux 2.6 kernel and is based with an IMX SoC - https://en.wikipedia.org/wiki/I.MX#i.MX_25_family

Anyway, It's ARM, so how hard can this be I thought ;-) Looking at the Make file for "armhf", this seems to build directly on rpi 3/4, so I thought hey, I can cross compile on Ubuntu and copy across to the device.. what was I thinking!!??

Anyway, after days of fighting with cross compilation, I've got an executable that runs on said device.. As it's dynamically linked I've had to copy many libraries across to said "radio", but now these dependencies have all been resolved I get C library dependency I cant seem to resolve.

Yup, I;m well outta my depth here. Do I statically compile all of the libraries instead ? I've had a go at that and I get more errors..

So, close, yet so far away haha. .What CLib library version is the SnapClient targetting? I think I'm using the right words, but I'm treading water/platting snot here.. Any advice would be welcome

Cheers muchly x

[TotalSpaceshipguy]

TL;DR (as the kids say) - I've more or less given up (for now), but learnt so much :-) Too bad cos these "radios" go real cheap on fleaBay and would have made acceptable looking speakers for small rooms. Ministry Of Sound can rest easy .. for now.

OK, I realise that my prior questions was a tad dense in a n00b kinda way (hence no answers I guess - sorry). Even though I've so far failed at this project, I've actually learnt a sh*t tonne and that's what count eh!

So, the cross compilation toolchain is linking against the libc version I have on the host system, so when I run the executable on the target, it's looking for the libs of that version (2.32) because I'm cross compiling on the latest Ubuntu (21.04).

Rewind.... So, I had to heavily doctor the Makefile to create a platform specific build of the snapclient. I found out the hardware in this device is armv5 which is armel, not armhf which is armv7 upwards. To compile I had to get needed armel compatible libraries firstly. Sod building from source, so I headed over to the Debian package search and got the necessary armel .debs and extracted what I needed to get the compile to finish. After several days of grinding teeth I had an armel compatible snapclient... w00t I can has a cookie.

Alas, I was too smug, and running the custom snapclient executable resulted in missing library errors. OK, I copied these across to the /lib folder on the "radio" via scp (yes, this thing has a ssh daemon!). All was well and there was a glimmer of light at the end of the tunnel, or so I thought! Copying the libraries across went OK... until I tried to upgrade the glibc libs and that jut hosed the radio which wouldn't then boot * sadface * . Many firmware resets later I needed a new plan (stan).

This is where I discovered the LD_LIBRARY_PATH environment variable which gave me a false sense of success.. and then I hit errors like this..
/snapclient: /lib/libc.so.6: version `GLIBC_2.32' not found (required by ./snapclient)

Grrr.... After much searching this is where I found out the cross compiled executable expects the same glibc library as the host it was compiled on and not the version on the radio, and of cousre and previous attempts to copy over newer versions had ended in disaster requiring a full device reset.

All was lost I thought... until I discovered the LD_PRELOAD environment variables. OK, maybe I can preload newer glibc libs I foolishly thought.. Nope, this went well with a few libraries but eventually ended in " module ignored" errors and segfaults * double sadace *

After much head scratching it seemed I'd resigned myself to the fact I would have to cross compile the glibc libs from source to get an up to date version, but the README put the final cock blocking nail in the coffin when I saw "When working with Linux kernels, this version of the GNU C Library requires Linux kernel version 3.2 or later"

Ultimately, the old kernel on this device hath right royally f*ckethed me over.

I guess the only way to build a compatible executable would be to do either spin up an older Ubuntu OS with an older cross compile toolchain, or just compile the source directly on the actual device.. Yea right.. this thing is so resource constrained I couldn't possibly copy all the required source on there, and as the processor runs at something like 200MHz I'd be dead by the time it finished lol.

Maybe I could compile on some equivalent emulated hardware and achieve great success ? That's for another day tho ;-)

• FIN *

[kuenkin]

Hello,
This would be awesome...did you continue the investigation?