MidiHub editor on Fedora crashes on launch

Midihub Support
1

Opening a separate topic on this as per the request in Documentation of Editor Protocol - #13 by Giedrius

So while fiddling around waiting for the MidiHub to arrive, tried running the latest image on Fedora 31 (x86_64), but it fails to start:

[pmatilai@mursu Download]$ ./MidihubEditor_1.11.0.AppImage
Setting $HOME to /home/pmatilai/Download/MidihubEditor_1.11.0.AppImage.home
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_num_locks
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_id_callback
qt.network.ssl: QSslSocket: cannot resolve CRYPTO_set_locking_callback
qt.network.ssl: QSslSocket: cannot resolve ERR_free_strings
qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_cleanup
qt.network.ssl: QSslSocket: cannot resolve EVP_CIPHER_CTX_init
qt.network.ssl: QSslSocket: cannot resolve sk_new_null
qt.network.ssl: QSslSocket: cannot resolve sk_push
qt.network.ssl: QSslSocket: cannot resolve sk_free
qt.network.ssl: QSslSocket: cannot resolve sk_num
qt.network.ssl: QSslSocket: cannot resolve sk_pop_free
qt.network.ssl: QSslSocket: cannot resolve sk_value
qt.network.ssl: QSslSocket: cannot resolve SSL_library_init
qt.network.ssl: QSslSocket: cannot resolve SSL_load_error_strings
qt.network.ssl: QSslSocket: cannot resolve SSL_get_ex_new_index
qt.network.ssl: QSslSocket: cannot resolve SSLv23_client_method
qt.network.ssl: QSslSocket: cannot resolve SSLv23_server_method
qt.network.ssl: QSslSocket: cannot resolve X509_STORE_CTX_get_chain
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_noconf
qt.network.ssl: QSslSocket: cannot resolve OPENSSL_add_all_algorithms_conf
qt.network.ssl: QSslSocket: cannot resolve SSLeay
qt.network.ssl: QSslSocket: cannot resolve SSLeay_version
qt.network.ssl: QSslSocket: cannot call unresolved function SSLeay
qt.network.ssl: QSslSocket: cannot call unresolved function CRYPTO_num_locks
qt.network.ssl: QSslSocket: cannot call unresolved function CRYPTO_set_id_callback
qt.network.ssl: QSslSocket: cannot call unresolved function CRYPTO_set_locking_callback
qt.network.ssl: QSslSocket: cannot call unresolved function SSL_library_init
qt.network.ssl: QSslSocket: cannot call unresolved function SSLv23_client_method
qt.network.ssl: QSslSocket: cannot call unresolved function sk_num
Segmentation fault (core dumped)

This is due to incompatible openssl libraries: these symbols exist is 1.0.x but were removed in 1.1.x (1.1.1d here). It doesnā€™t help that openssl doesnā€™t follow common soname practises it seems. Which might have something to do with Qt dlopen()'ing the stuff it needs instead of linking but dunno.

So itā€™d seem that at least the libssl and libcrypto need to be bundled in the appimage (and perhaps Qt directed to look for it there) to get this to run. Looking at the other bundled libraries in squashfs-root/usr/lib, they have quite a few dependencies of their own that resolve back to the host:

[pmatilai@mursu lib]$ LD_LIBRARY_PATH=$(pwd) ldd *|awk ā€˜/lib64/{print $3}ā€™|sort -u
/lib64/libbz2.so.1
/lib64/libc.so.6
/lib64/libdl.so.2
/lib64/libdrm.so.2
/lib64/libexpat.so.1
/lib64/libfontconfig.so.1
/lib64/libfreetype.so.6
/lib64/libgcc_s.so.1
/lib64/libGLdispatch.so.0
/lib64/libglib-2.0.so.0
/lib64/libGL.so.1
/lib64/libGLX.so.0
/lib64/libgpg-error.so.0
/lib64/libharfbuzz.so.0
/lib64/libICE.so.6
/lib64/libm.so.6
/lib64/libpcre.so.1
/lib64/libpng16.so.16
/lib64/libpthread.so.0
/lib64/librt.so.1
/lib64/libSM.so.6
/lib64/libstdc++.so.6
/lib64/libuuid.so.1
/lib64/libX11.so.6
/lib64/libxcb.so.1
/lib64/libz.so.1

Thereā€™s obviously a whole bunch of low-level stuff that can expected to stay ā€œforeverā€ like anything from glibc origin, but the further into GUI layer you get the more volatile these things tend to get. This is not any way specific to MH editor of course, binary compatibility across Linux distros and their versions is just a sad heap :slightly_frowning_face:

2

Oh, now that I set out to look into it, itā€™s pretty strange: strace shows it looks for unversioned libcrypto.so and libssl.so names first. As I usually have openssl-devel installed, it finds them and crashes as per above. However if I uninstall openssl-devel, it then goes on to look for these libraries by other sonames and starts up fine. But of course the unversioned libcrypto.so and libssl.so are just symlinks to the very same libraries it ends up happily using by another name. I havenā€™t looked, but seems as if there are some funny version heuristics in Qt5, openssl version compatibility has been a common PITA.

Edit: And now that I actually look, thereā€™s a whole source-file dedicated to this very task :joy: :
https://code.qt.io/cgit/qt/qtbase.git/tree/src/network/ssl/qsslsocket_openssl_symbols.cpp

Quoting the starting comment:

We load OpenSSL symbols dynamically. Because symbols are known to
disappear, and signatures sometimes change, between releases, we need to be careful about how this is done. To ensure we donā€™t end up dereferencing null function pointers, and continue running even if certain functions are missing, [ā€¦]

I guess you could call it a Qt bug too, because it clearly fails to accomplish what it goes to great lengths trying to achieve.

1 Like
3

Hey, could you try this build out - it has the SSL dependency disabled in Qt, so should no longer cause problems. :slight_smile:

1 Like
4

Tested on Fedora 31 and 32, 1.11.1 image starts fine on both regardless of installed (or not) openssl foobar. Now if I only had the device itselfā€¦ :sweat_smile:

Thanks!

1 Like
5

Thank you for verifying! :slight_smile: