-
Notifications
You must be signed in to change notification settings - Fork 3.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
maybe include glibc
in appimage, for better(?) compatibility
#7997
Comments
Right... We've recently (#7926, in 4.3.2) changed the builder image base from ubuntu 18.04 to debian 10. so the 4.3.2 appimage does not run on ubuntu 18.04 :/ I don't know what the consequences of bundling glibc would be. It is not done by default when using appimagetool. related: |
glibc
in appimage, for better(?) compatibility
Ubuntu 18.04 here, same problem of course. I wonder if there is any a chance that two versions of the AppImage are built and offered for download, e.g. electrum-4.3.2-x86_64.AppImage (This glibc problem is alas what makes Linux "a moving target" to be avoided for many hardware vendors, e.g. of audio interfaces. It would be great if the Linux community could find a solution.) |
I admit that I had arrived here looking for solutions for the same problem with another application, MuseScore4, which requires glibc-2.29. It turns out that they also distribute MuseScore4 as Flatpak, which solved the problem, their software installed via Flatpak works fine on Ubuntu 18.04.5. Before finding that out, I had learned how to get and build and install other glibc versions without breaking the system. Basically (notice that this didn't work out), after retrieving glibc-2.28 and building and installing it into a non-root tree (which was trivial (*) per se once I found the info on how to do it, and took less than 5 minutes if building using all the CPU cores on this old PC), I'd launch a script containing:
Result:
I upgraded the system and rebuilt glibc-2.28, same error. Maybe I should search for glibc-2.28 binaries built on a glibc-2.28 Linux, or install Fedora (11?) [EDIT: Debian 10] on another disk/PC and build glibc-2.28 on it (if it's not already coming with glibc-2.28). Anyways, I searched for info and here I found a link to this page explaining the origin of that version matching requirement (something of doubtful utility IMO introduced in 2010 to allow one binary build to cover optimizations for different variants of sparc64 CPUs instead of automating the build of different binaries, making Linux even more of a moving target). Anyways the only "solution" I found was to switch to a more recent Linux distribution, which I don't want to do on this PC, so it's not a solution (the "moving target" philosophy contributes to hardware vendors taking the decision not to provide their software for Linux as well, e.g. Focusrite). (*) I see that there's a less trivial way to build glibc, which includes also building gcc, in this page chapter "Setup 2: crosstool-NG pristine setup". Of course I wouldn't take that path without having checked how that works, in order to be sure that I'm only creating a "local" glibc-2.28 and I'm not damaging the system. Exactly the same happened with MuseScore4 and glibc-2.29, except that later I realized that they offer a Flatpak alternative which works fine (including MIDI input/output via USB and audio output). After the (extremely slow) download of the necessary components, this turns the startup script into:
Bottom line: Maybe Electrum could offer a flatpak alternative as well, but I don't have any idea what amount of work / trouble that would imply so I'm not really asking, I'm just reporting about a similar situation for which that alternative was offered, and the developers will evaluate (if they haven't already). I am well aware that Electrum already offers python (3.8) source code among the download options. |
Update: I wanted to give a quick try and run Electrum via python3.8. I went to the Electrum download page and followed the instructions, starting with the dependencies:
I downloaded and built python3.8 from source as explained in this page, I used the "altinstall" recommendation not to override the system python (that might be part of the problem). I downloaded the Electrum Python sources and checked the signature (but used curl because with wget I was getting time out error after a long while [that happened for the first time a few weeks ago on another website and in that case as well curl did it]). I extracted and tried to run Electrum:
I double-checked the dependencies, same result. I installed python3-pycryptodome (3.4.7-1ubuntu1), without the ending x, same error trying to launch Electrum. Is there a python command I should issue to install at least one of ('pycryptodomex', 'cryptography') so that the python3.8 altinstall can use it? |
The
|
Thank you @SomberNight!
I'll leave the PC on it for a while (but eventually might ctrl-c that and issue the same command again). |
Hmm. It's weird that it's trying to build from source instead of using a pre-built wheel (which is the default behaviour). |
It's AMD64, but I got warnings about the version of pip recommending an upgrade, which I did like this (no sudo => permissions error):
Afterwards I could install cryptography and pyqt5 very quickly, thank you. Electrum starts, apparently it lacks libraries for Ledger / Trezor devices:
I'm going to see if I can install all those requirements the same way. |
Update:
|
Update: I launched it again anyways to see possible incompatibilities in what could be installed.
The Electrum 4.3.1 AppImage is working correctly on Ubuntu 18.04.6 as far as I can tell. |
After an upgrade from Linux Mint 19.3 to 20.3 the AppImages run fine. |
The following error is thrown after the start of electrum-4.3.2-x86_64.AppImage on Linux Mint Tricia 19.3:
/tmp/.mount_electrM7XUA6/usr/bin/python3: /lib/x86_64-linux-gnu/libc.so.6: version 'GLIBC_2.28' not found (required by /tmp/.mount_electrM7XUA6/usr/lib/libpython3.9.so.1.0)
This may be because the Linux Mint 19.3 distribution did not manage to update GLIBC to a version beyond 2.27
Would it be possible to include the needed GLIBC v2.28 in the AppImage?
Thank you so much for all your efforts for all of us.
Thank you!
richard
The text was updated successfully, but these errors were encountered: