Keepassxc: RHEL 7.7 - /lib64/libstdc++.so.6: version `GLIBCXX_3.4.21' on version 2.5.0

Created on 30 Oct 2019  路  28Comments  路  Source: keepassxreboot/keepassxc

Expected Behavior

I've been using Keepassxc for a while (mostly on RHEL7 and Fedora). Version 2.4.3 worked fine so I expected that 2.5.0 would too.

Current Behavior

$ ./KeePassXC-x86_64.AppImage
keepassxc: /lib64/libstdc++.so.6: version GLIBCXX_3.4.21' not found (required b y keepassxc) keepassxc: /lib64/libstdc++.so.6: versionCXXABI_1.3.9' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libQt5Svg.so.5)
keepassxc: /lib64/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libQt5Concurrent.so.5) keepassxc: /lib64/libstdc++.so.6: versionCXXABI_1.3.9' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libQt5Network.so.5)
keepassxc: /lib64/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libQt5Widgets.so.5) keepassxc: /lib64/libstdc++.so.6: versionCXXABI_1.3.9' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libQt5Gui.so.5)
keepassxc: /lib64/libstdc++.so.6: version CXXABI_1.3.9' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libQt5DBus.so.5) keepassxc: /lib64/libstdc++.so.6: versionCXXABI_1.3.9' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libQt5Core.so.5)
keepassxc: /lib64/libstdc++.so.6: version CXXABI_1.3.8' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libQt5Core.so.5) keepassxc: /lib64/libstdc++.so.6: versionGLIBCXX_3.4.21' not found (required b y /tmp/.mount_KeePasuJydgm/usr/lib/libQt5Core.so.5)
keepassxc: /lib64/libstdc++.so.6: version CXXABI_1.3.8' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libicui18n.so.55) keepassxc: /lib64/libstdc++.so.6: versionCXXABI_1.3.8' not found (required by /tmp/.mount_KeePasuJydgm/usr/lib/libicuuc.so.55)

Possible Solution

Were your build systems upgraded to a version that doesn't provide backward compatibility as far as RHEL7?

Steps to Reproduce

Install RHEL7/Centos7 (currently RHEL7.7), try to run KeePassXC-2.5.0-x86_64.AppImage

Context

KeePassXC doesn't start so I am unable to access my data. I've reverted back to 2.4.3:

Libraries:

  • LIBS

Operating system: RHEL7.7
CPU architecture: x86_64
Kernel: 3.10.0-1062.4.1.el7

downstream

Most helpful comment

@phoerious++
Thank you so much, it worked perfectly. I'm now running 2.5.0 on RHEL7 using my custom-built AppImage. I hope I can keep doing this in the future..
For the record, here are the steps I took:

$ git clone https://github.com/keepassxreboot/keepassxc.git
$ cd keepassxc
$ ./release-tool build -n -d keepassxc/keepassxc-ci:trusty-qt5.10 -v 2.5.0 --appimage

After the build completed (on RHEL7, even), I found this file:

$ ls -l release/KeePassXC-2.5.0-x86_64.AppImage
-rwxr-xr-x. 1 raistlin users 34992104 Nov 4 14:07 release/KeePassXC-2.5.0-x86_64.AppImage

I launched it and it works perfectly on RHEL7.
I suspect this will only last until KeepPassXC -can- build on Trusty (please mind the users who have a 10yo glibc, like me).
Thank you so much for your help. I'm very relieved.. I was beginning to lose sleep over this..

All 28 comments

We don't maintain the RHEL package, please contact the maintainer.

This is the AppImage. RHEL7 has a Glibc that is too old. We only support Ubuntu 16.04 and upwards or comparable systems.

RHEL 7.7 is comparable

RHEL7 comes with GCC 4.8 (CXXABI_1.3.7), Ubuntu 16.04 comes with GCC 5 (CXXABI_1.3.9).

The solution would be to download and install libstdc++.so.6.0.21 or higher, which defines GLIBCXX_3.4.21 and CXXABI_1.3.9 and then set LD_LIBRARY_PATH accordingly. The default in RHEL7 is libstdc++.so.6.0.18, I believe, which is ancient.

Enterprise Linux :grin:

RHEL7 is about as old as Ubuntu 14.04, but offers support for 10 years+. Unlike Ubuntu, they do not offer any newer release before the previous one goes EOL, though.

RHEL is about long term support and features through backports. Obviously, rebasing glibc is not one of them. I'm guessing that the .AppImage would work fine on RHEL8 (but I'm on RHEL7) and I find it a little sad that none of the people responsible for KeepassXC have even cared to mention that the minimum requirements were bumped up when 2.5.0 came out.
Is there really no way to go back to building with the previous libs? (2.4.3 was fine)

It was mentioned in the release announcement.
We cannot go back and build with Trusty for two reasons: 1) Trusty is EOL and does not receive security updates anymore 2) other basic libs which we cannot bundle properly started to become incompatible with newer systems, such as OpenSSL.

Now we could run Xenial with a downgraded libstdc++/Glibc, but then we would have to compile every bundled lib from source code for it to have an effect (libstdc++ is not actually part of the AppImage, which is why you are seeing this error).

The RHEL package maintainers are responsible for getting a native built KeePassXC out the door. We are not capable of providing an AppImage deployment that satisfies every distributions crazy mix of obsolete software. I find it sad that RHEL 7 cannot provide a more updated C ABI.

We tried the move to a newer base image a while ago, but reverted to Trusty soon after when loads of bug reports flew in from people being unable to use the AppImage. At that time, many distributions such as Mint were still based on Trusty. Now, however, I don't see much of an alternative and I think its generally time to move on anyway. We also haven't seen any other reports in this regard so far, which is a good sign. RHEL/CentOS is rather special with their software stack and slow release cycle.

So, unless RedHat do something there's no way to install 2.5.0 ?
I was very happy with 2.3.4 and wished to upgrade.
I thought that Appimage included everything needed to run, that's a pity.

@phoerious Ok, thanks. it is clearer now. Thanks for sharing. I had somehow missed that ( and hadn't seen its unintended consequences on RHEL7). Have you guys considered building on CentOS, btw? Short of staying on 2.4.3 for ever, I could try building a keepassxc rpm on RHEL/Centos with its deps.

Not everything. Some libraries cannot be packaged. AppImages are not a virtual machine.
We did consider building on CentOS a while ago, but it turned out to be way too complicated as almost every package, including Qt, had to be compiled from source. That also wouldn't solve the problem of OpenSSL becoming incompatible with newer systems.

This is true and I totally understand. Perhaps the right solution for me (perhaps other too) would be to run the AppImage in a container.. There appears to be one at https://hub.docker.com/r/keepassxreboot/keepassxc/tags but it doesn't look maintained.
Do you think that would work for desktop integration with e.g Chrome on Linux?

There's also https://github.com/jessfraz/dockerfiles/blob/master/keepassxc/Dockerfile from Jessie Frazelle (thanks to here) which appears more focused on containerizing keepassxc. I'm trying to work from that.

I've put my (unfinished work) here : https://github.com/ElCoyote27/docker-keepassxc
I do seem to have KPXC 2.5.0 working on RHEL7 (it starts) but I'm currently struggling to have google chrome recognize it..

You can just checkout the old trusty-Version of our build image and use that to build the AppImage. The release-tool script makes that easy.

./release-tool build -n -d  keepassxc/keepassxc-ci:trusty-qt5.10 -v 2.5.0 --appimage

Please be aware, though, that this might stop working in the future. This already uses a newer Qt version (the default 5.2 became unsupported), but we will not be testing compatibility with GCC version 4.8 anymore.

@phoerious Ah, that's a very very good idea. Is there a place I can ask further questions about this (do I need to setup a Trusty VM or can I just use your build image to rebuild the AppImage itself)?
Thank you for your help,

That command should work as is and will pull the image from Docker Hub. You can always ask questions on matrix/IRC.

@phoerious++
Thank you so much, it worked perfectly. I'm now running 2.5.0 on RHEL7 using my custom-built AppImage. I hope I can keep doing this in the future..
For the record, here are the steps I took:

$ git clone https://github.com/keepassxreboot/keepassxc.git
$ cd keepassxc
$ ./release-tool build -n -d keepassxc/keepassxc-ci:trusty-qt5.10 -v 2.5.0 --appimage

After the build completed (on RHEL7, even), I found this file:

$ ls -l release/KeePassXC-2.5.0-x86_64.AppImage
-rwxr-xr-x. 1 raistlin users 34992104 Nov 4 14:07 release/KeePassXC-2.5.0-x86_64.AppImage

I launched it and it works perfectly on RHEL7.
I suspect this will only last until KeepPassXC -can- build on Trusty (please mind the users who have a 10yo glibc, like me).
Thank you so much for your help. I'm very relieved.. I was beginning to lose sleep over this..

I'm able to run 2.5.1 on RHEL 7.7 using the snap version.

  1. Install snapd on RHEL according to the following:
    https://snapcraft.io/docs/installing-snap-on-red-hat
    Make sure you follow the instructions at the bottom to create the symlink.
  2. Install the keepassxc snap:
    sudo snap install keepassxc
  3. Launch keepassxc from the snap:
    /snap/bin/keepassxc
  4. Enable browser integration via the settings menu.
  5. Download and run the keepassxc-snap-helper.sh script from the KeePassXC download page: https://keepassxc.org/download/#linux
    (This tells your browser how to launch the proxy from the snap)

Oh, that's interesting. Thank you for sharing this, Ed.

Hi, CentOS 7 user here.
Any chance of hosting the trusty-built appimage somewhere ? snap is not an option for me (long story)
(Yes, I could install trusty myself and build it, but... since it is already been done and going to happen repeatedly until we RH users migrate to RH8 or something else happens...)

That's a good idea. Let me put it up on my website quickly.
BTW, it's very simple to rebuild.. you only do that through containers - I did so on RHEL7.

@ElCoyote27 THANK YOU!
Works like a charm.

PS: containers and snap mean the same difficulty for me right now.

@scaprile You can thank @phoerious I almost did nothing. It was a oneliner to build it.

Yes, I see, @phoerious did the brain work, thank you!
Next update I could give the build process a shot. No time right now (and disk space low)

Was this page helpful?
0 / 5 - 0 ratings