Hutspot for aarch64?

Can you post some errors? It’ s on the list of apps I’ve put together to get a port for but I suspected it needed api changes. ON the other hand if you were using it recently on the pinephone, maybe it’s not an api issue?

From my experience, Hutspot works just fine on 32-Bit, it only needs an aarch64 version.

If I try to compile it with Sailfish SDK, I get 16 errors.
The mos common one is this one:
Error: invalid use of incomplete type ‘DH’ {aka ‘struct dh_st’}
…/hutspot/src/connect/spconnect.cpp:41:31: error: invalid use of incomplete type ‘DH’ {aka ‘struct dh_st’}
BN_rshift(dh->priv_key, dh->priv_key, 8);
This error I get multiple times.

Then there is also this error:
/src/connect/spconnect.cpp:173: Error: ‘AES_ctr128_encrypt’ was not declared in this scope
…/hutspot/src/connect/spconnect.cpp:173:5: error: ‘AES_ctr128_encrypt’ was not declared in this scope
AES_ctr128_encrypt((const unsigned char *),
…/hutspot/src/connect/spconnect.cpp:173:5: note: suggested alternative: ‘AES_cfb128_encrypt’
AES_ctr128_encrypt((const unsigned char *),

I’m just learning C++ right now, so I’m not very good at it yet, but these errors seem to me as if I’m doing something wrong during compiling.
It can’t be that there are such errors, like something not beeing defined, can it?

I believe this has to do with the openssl code being ahead of the original code. Since this is crypto code I’m going to send it back to the author and see if they respond.

Openssl was also my first guess.
But unlike you wrote in your bug report, these issues are not specific to aarch64.
I also get these errors when trying to compile for armv7hl and i486

Yes, I only built one target. But a library like openssl is generally going to be identical. These issues are certainly related to developments in the interface of the library. But since it’s crypto in the connection management, I’m not comfortable going there. I hope the author responds.

EDIT: probably related to:

TLDR: Use DH_get0_pub_key(key) to get hold of the pub_key value instead of key->pub_key

All these cases will need to be rewritten

BN_rshift(dh->priv_key, dh->priv_key, 8);


I’ve read that you could also “build against” a different Openssl version. I have Openssl 1.02 in /usr/local, but not sure how to direct make to use that instead of built-in Openssl, (currently v. 1.1.1)…

Jeez. I wouldn’t advise it, but it should work. Openssl is a mine field. Perhaps you could mention how you’d do that in the SDK context?

I’m pretty much on-device mostly. I just built Openssl from source and installed to /usr/local, so I have 1.02 in /usr/local, and 1.1.1 in /usr.

The errors I’ve seen in forums that match up to the op usually are from a program trying to be built with a newer verof Openssl than the one it was written for, so typically there would be a patch needed. But, one answer I read said you coul “build against” a different version of Openssl. I’m just not sure how to edit which file to make that happen.

Well, one could go ‘the hard way’. But that would require making the project subdirs based (or the like) and adding the open ssl locally to the project. Then you could install it to /usr/share/appname/lib … I only have one project like that (with a small c++ library) and that’s manageable. It’s doable, for sure. I just wouldn’t do it :slight_smile:

Just to illustrate:
Excerpt top project:

    libsynth \

Excerpt the lib pro file:

CONFIG += staticlib

Excerpt the main app pro file:

LIBS += -L$$OUT_PWD/../libsynth/ -lsynthetizer
QMAKE_RPATHDIR += /usr/share/$${TARGET}/lib
SOURCES += src/harbour-simplesynth.cpp \
# Headers
HEADERS += 	../libsynth/include/libsynth.hpp \
INCLUDEPATH += ../libsynth/ \

But I’m really hoping the author of the package responds.

If support for OpenSSL 1.0 is dropped in 4.3, than this “fix” wouldn’t work anymore, right? So Hutspot basically needs to be rewritten

It’s not a complete rewrite, just those with use of the dh->pub_key access style. So the structs member, you have to use the method. I don’t know how much work it is, but it shouldn’t be more than an hour or two. If I wasn’t debugging other stuff AND had a spotify account (don’t use it) I’d do it.

I tried to rewrite all of the dh->pub_key and dh->priv_key according to the OpenSSL manual. I’m now getting conversion erros, which I’m trying to fix, but this is very difficult for me. Also I don’t now how to replace dh->p=… and dh->g=… since there are no DH_set0_… for these (or I just don’t understand this right).

This is really non-trivial stuff. I’m a bit snowed in at the moment, but I’ll have a look as soon as I can find some time …

1 Like

The issue led to patches

Someone actually did rewrite the priv_key stuff, yeah!

changes came from Scarrough · GitHub

I implemented those and PR:

A build for you to test:

Please let me know if this is working for you. I don’t even have a spotify account, let alone a premiums account!


I built it myself, and after swapping to the new WebView i can log in and control playback on another device. I still have issues navigating the app, but i think that is the way it was. Throwing a PR at @poetaster soon.

1 Like

Thank you very much! I’ve tested the app and it works perfectly fine!
Now we only need someone to re-package librespot for aarch64 (unfortunately I’m not able to do this myself…)

Thanks @poetaster , and I want to confirm that your build of Hutspot also works on the XA2. I’m very grateful for your efforts. After starting librespot from the terminal and starting Hutspot, I could instantly start playing music on my XA2. I’ve missed that functionality for months, great that it’s back!

Thanks! I’ve had enough positive feedback that I’m willing to push it to chum and see if I can support it.


Thank you for your effort, I really apreciate that

If someone would suggest the correct Sailjail permissions?

Something like: