Hutspot for aarch64?

Hi there,

I used Hutspot on my PinePhone and it worked really well. Now SailfishOS on the PinePhone is aarch64 and there is no Hutspot available, and the developer hasn’t committed since 2019. So I decided to build the app myself. But when building Hutspot with the SailfishIDE or librespot with cargo I always get errors.
Am I doing something wrong or is the Hutspot-Code really faulty?


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.