Keepassxc: Cannot launch 2.6.2 on macOS 10.13

Created on 22 Oct 2020  路  29Comments  路  Source: keepassxreboot/keepassxc

This doesn't seem to do the trick. I'm wondering if the minimal system requirements have been levelled up with this new minor release ? I'm asking because of the error message I've pasted below. It mentions OSX 10.15.

Dyld Error Message:
Symbol not found: ____chkstk_darwin
Referenced from: /Applications/KeePassXC.app/Contents/MacOS/../Frameworks/libgcrypt.20.dylib (which was built for Mac OS X 10.15)
Expected in: /usr/lib/libSystem.B.dylib

_Originally posted by @wisobe in https://github.com/keepassxreboot/keepassxc/issues/5347#issuecomment-714138712_

build system macOS

All 29 comments

I confirm the same while using v10.13.6 (High Sierra):

Dyld Error Message:
  Symbol not found: ____chkstk_darwin
  Referenced from: /Applications/KeePassXC.app/Contents/MacOS/../Frameworks/libgcrypt.20.dylib (which was built for Mac OS X 10.15)
  Expected in: /usr/lib/libSystem.B.dylib

The Homebrew maintainers refuse to see how this is an issue, so we cannot do anything about it right now. I suppose we have to dump brew in the future, since this way it's entirely useless, even if the fix is entirely trivial and I wouldn't even expect them to test anything on older macOS versions. Unfortunately, I don't really see an alternative right now. Building for macOS is a total nightmare, especially if the only projects making it less so fail at doing their job.

I'll try to get to it later, but someone should set some code in the ruby(?) script to catch users that will be in jeopardy.

To explain, I have successfully downgraded to v2.6.1, and it seems to function without problem as before the upgrade to v2.6.2 However, brew users of macOS > v10.12 (Sierra) & < v10.15 (Catalina) are impacted as it will leave their installation non-functional unless they uninstall with brew and download from the KeepassXC site, hopefully authenticating the signature and/or hash before installation.

KeePassXC installed via brew won't work either, since brew only pulls our binary. So in that sense, they shot themselves in the foot. They refuse to make their binaries more compatible and in return they accept that even if installed via brew on < 10.15, some applications won't work no matter what. In consequence, that means brew isn't compatible with anything other than 10.15, even if you are using it on 10.14 for the exact purpose it's intended for.

I got bitten by this today as well. Downloading the 2.6.2 dmg directly has the same issue, so I had to dig a bit to find the 2.6.1 dmg to install. Point being, this doesn't seem to be a brew-specific issue.

This isn't a brew-specific issue. Also downloaded 2.6.2 dmg directly and it does not work with the same error. I'm using v10.13.6 (High Sierra).

I'm running 10.14.6 and upgraded with 'brew cask upgrade' and it works fine. Is there more to this story perhaps?

Check which libraries are loaded. It should fail if you are using the libraries bundled with KeePassXC. You can, of course override the load path at runtime.

This only fails on 10.13

This might be a completely separate issue, but I cannot install 2.6.2 from the dmg on current MacOS 10.15.7. MacOS is reporting that the extracted app is damaged (nothing more useful than that). I verified against the digest, and ran multiple downloads with the same result. I backed off to 2.6.1 for now, but would love to know if this is a local issue or whether it's affecting others. Thanks for your work on an otherwise excellent package!

Thats a local issue to you, usually resolved with a restart.

I run into the same problem on macOS 10.13. I am not savy on debugging, but from the error message I receive I got the impression that it might be the missing libgcrypt.20.dylib, which according to the message was built for MacOS 10.15 and is thus not in place on 10.13?

"Termination Reason: DYLD, [0x4] Symbol missing

Dyld Error Message:
Symbol not found: ____chkstk_darwin
Referenced from: /Applications/KeePassXC.app/Contents/MacOS/../Frameworks/libgcrypt.20.dylib (which was built for Mac OS X 10.15)
Expected in: /usr/lib/libSystem.B.dylib"

We know what the problem is, we simply do not have a practical fix at the moment.

Thats a local issue to you, usually resolved with a restart.

Confirmed and successfully installed. Thanks for clue issuance, DM!

Can you please try this DMG? link expired (it's signed and all)

Hi ! It works for me. :-) That's a fast solution. Thanks a lot. :-)

It wasn't particularly fast for me, since I had to recompile everything from source, including Qt. For the time being it would have been enough to compile only libgcrypt, but for a future-proof solution, we cannot rely at all on Homebrew's bottles, which are potentially incompatible with anything but 10.15, simply because of a missing compiler flag.

Unfortunately, Homebrew is a beast and the only way to fix this was to patch their superenv shim in order to set MACOSX_DEPLOYMENT_TARGET=10.13. There doesn't seem to be any other way to set compiler flags. Any HOMEBREW_* env vars are totally ignored and can apparently only be set from within a formula. @jonchang @SMillerDev If you are reading this, please consider that backwards-compatible binaries or at least a way to set your own compiler flags has been requested by many people for many years.

As always, I updated the DMG link on the website. 馃檮

We've already explained to you extensively why we cannot do this. Tagging Homebrew maintainers in unrelated projects won't help solve the fundamental issues we've raised and you've dismissed.

Oh, so adding a feature to allow users to set their own compiler flags is also impossible, but full manual --interactive mode is a thing? I really don't understand you guys or what potential target user you are envisioning.

@jonchang Cannot do this != Won't do this. I've refused a lot of requests for KeePassXC because it's too difficult or for a small audience. We aren't fly by night requestors... pick your battles

This is not productive. I've already outlined that if you want binaries to work on 10.13, you need to compile with 10.13. If this is not sufficient for you, please consider using another package manager.

@jonchang And I have outlined that there is an easy fix to allow 10.15 binaries to run on 10.13 with absolute NO extra work on your side. You don't have to test or officially support anything but what you are doing already, yet it magically works on more platforms. Or at least it gives me the opportunity to enable this behaviour for MY binaries, which concerns you even less (but requires an option to pass on compiler flags, which is useful not only for this scenario).

According to the docs, bottles ARE designed for redistribution and you are already doing the exact same thing for CPU architectures, so your whole stance seems counter-intuitive to me.

By default, bottles will be built for the oldest CPU supported by the OS/architecture you鈥檙e building for (Core 2 for 64-bit OSs). This ensures that bottles are compatible with all computers you might distribute them to.

https://docs.brew.sh/Bottles

@phoerious, as a workaround, you can create your own tap, copy the libgcrypt formula there, add:

ENV["MACOSX_DEPLOYMENT_TARGET"] = "10.13"

to the beginning of the install block, build it with brew install phoerious/tap-name/libgcrypt and there you go.

I did the same thing, but instead of creating my own tap and editing all the formulae, I patched the superenv. That's arguably uglier, but also arguably easier to maintain.

Ok, as a user that is affected by this, how can I get my KeePassXC back to working?
@phoerious Up a few comments you seem to have linked a DMG, but it say the link is expired. Is there some other link to get this dmg? Or do I just reinstall 2.6.1?

Just redownload from our website.

Thanks, I was just super confused since KeePassXC auto-updated and then it didn't work anymore. Realized now that I had it installed via brew and that it was automatically updated via a cron job.

Redownloading worked now, sorry did not realize that the version on the website was already fixed.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

JosephHatfield picture JosephHatfield  路  3Comments

nfnty picture nfnty  路  3Comments

rugk picture rugk  路  3Comments

TheZ3ro picture TheZ3ro  路  3Comments

n1trux picture n1trux  路  3Comments