Gnucash won't start



When I try to start gnucash I get the following error messages (and gnucash fails to start):

;;; WARNING: loading compiled file /usr/lib64/guile/2.0/ccache/ice-9/eval.go failed:
;;; Throw to key misc-error with args ("load-thunk-from-memory" "not an ELF file" () #f)
;;; note: source file /usr/share/guile//2.0/ice-9/eval.scm
;;;       newer than compiled /usr/lib64/guile/2.2/ccache/ice-9/eval.go
Uncaught exception:

Error while printing exception:
Key: stack-overflow, args: (#f "Stack overflow" #f #f)
Aborted (core dumped)

This is on a system that I just upgraded from Fedora 35 to Fedora 36. Gnucash was upgraded as part of the system update. I have another system where I performed the same upgrade and gnucash is still working for me there. I tried reinstalling guile, guile22, and gnucash but the problem persisted. I also checked that the versions of guile, guile22 and gnucash are the same on both systems. Originally the system having the problem had a slightly newer version of gnucash, but downgrading to the version on the other system did not help either

Relevant package versions:

  • guile-2.0.14-28.fc36.x86_64
  • guile22-2.2.7-5.fc36.x86_64
  • gnucash-4.11-3.fc36.x86_64 (downgraded from gnucash-4.12-1.fc36.x86_64)

I have the same 3 packages (the latest gnucash) and have never had an issue.
Maybe you could try sudo dnf distro-sync --allowerasing --refresh and see if that fixes the problem. It could be that some other package needs tweaking.

It also could be something in ~/.config/gnucash or ~/.gnucash or ~/.local/share/gnucash that is affecting the behavior on that system (I have all those on my system).

To test if it may be one of those directories under your regular user you might create a new user then log in as that new user and start gnucash. If it starts properly for the new user then it would be narrowed down to something in your regular users home directory that is interfering.

Just use flatpak on flathub

I think that when fully functioning apps are available in the fedora repo that it seems counterproductive to recommend flatpaks.

Flatpaks are not subjected to the same testing and verification process as fedora rpms and thus may (or may not) have other errors.

They also may not be updated to the latest versions as quickly as fedora supplied rpms if that is of concern to the user.

Flatpaks are great for use with silverblue, kinoite, etc, but really should not be first choice for workstation or other spins.


Thanks for those suggestions. Unfortunately it isn’t working yet.

I see the same behavior under the new user account.

The above command did update some packages and remove an old kernel, but the problem still occurs after running the above and rebooting the system.

Did you do the distro-sync before or after the test with the new user. If before then any pre-existing errors may have been introduced to the new user. If after then it seems strange that a new user would see the same problem.

One really extreme possibility would be to do a full system reinstall – live – using dnf reinstall '*' --refresh --allowerasing and allow it to fully reinstall every single package on the system. Following that create another new test user and try gnucash again.

Just out of curiosity, what additional software may be installed on the system in question that might not be installed on the other systems that work properly? More stuff from fedora? Something from a 3rd party repo or compiled locally?
These questions are trying to identify exactly what, if anything, is different between the working system and the problem one.

Both; I tested with the test user account, then did the distro-sync, then deleted everything in the test user’s home directory and tested again. Same result both times.

That might actually be worth trying. This system has been upgraded through numerous Fedora versions. The F35 to F36 upgrade seemed to go smoothly, but some of the previous ones didn’t. Most egregiously, a partition filled up during upgrade from F34 to F35. I cleaned up the resulting mess as best I could, but it’s possible something got missed in the process, and reinstalling every package is more thorough than the things I did up to now. I’ve started the process and I’ll report back once it finishes.

There are certainly lots of differences between the two in terms of what packages are installed. The one that I can think of that’s most likely to affect is this system has an nvidia video card, which means it has the nvidia drivers and runs Gnome on X11 as a result; the system that works properly has an Intel video card and I use Gnome on Wayland there. But the error messages I get don’t seem to be pointing to anything graphics related so I’m disinclined to suspect the nvidia driver or X11 as a likely cause of the problems.

To be sure, I ran rpm -qR gnucash|xargs rpm -q --whatprovides and got essentially the same list of packages (only a few small version differences here and there).

Update: Same behavior after reinstalling all packages, rebooting, and removing/recreating the test user.


I am almost out of ideas right now. My F36 system with gnucash has never had an issue. It was clean installed at 32 and upgraded since. I have used fedora with gnucash on that machine for more than 10 years, and only the one clean install in that entire time. I have rebuilt the system twice and the reinstall was when I switched the OS from HDD to SSD (/home was retained).

I agree that the graphics should not be an issue since I also use nvidia with the drivers installed from rpmfusion.

Are there any packages that you compiled and installed locally?
If so then it is quite possible that there may be some library file or something else that the package manager is not aware of which may be interfering.

If that is the case and you are unable to identify whatever may have been installed that way and uninstall it, then I can see there is a possibility that the only recovery may be a complete new install which would wipe out any interfering system files and only install those provided by fedora. Then avoid installing anything except by using the package manager unless you are prepared for potential side effects.



  1. This means a malformat file

Where is the Error?

The error is in front of our eyes:

;;; note: source file /usr/share/guile//2.0/ice-9/eval.scm
;;;       newer than compiled /usr/lib64/guile/2.2/ccache/ice-9/eval.go

one file is from 2.0 and the other is from 2.2, What is the corrupted lib? Who knows?

Questions here:

What is the necesary lib here? Answer Who knows?

Workaround, try that…

  1. delete with rpm all the guile package with --nodeps flag:
  • sudo rpm -e --nodeps guile-2.0.14-28.fc36.x86_64
  • sudo rpm -e --nodeps guile22-2.2.7-5.fc36.x86_64
  • sudo rpm -e --nodeps gnucash-4.11-3.fc36.x86_64
  1. Search for left-lovers in the _directories mentioned in the error and if exists delete it…
sudo rm /usr/share/guile//2.0/ice-9/eval.scm
sudo rm /usr/lib64/guile/2.2/ccache/ice-9/eval.go

and resintall gnucash which I’ve supossed it resintall all dependencies if necesary

Verify all guile packed

dnf list installed *guile*


Hrm, I just installed gnucash on my F36 here, and it ran fine:

$ rpm -qa gnucash \*guile\*

Since it works on one system and not on the other, it is probably not related to the rpm system packages. The ccache bit makes me think this is due to some compiler caching where a file compiled and cached by a previous installation still exists and needs to be removed.

I’d try Hector’s suggestions here to begin with. Let’s remove the packages and ensure that all files that these packages owned were also removed. You can get the file list using rpm -ql. So after you’ve removed the packages, you can check if these files still exist:

$ rpm -ql guile22

Thanks @ankursinha and @hhlp. I uninstalled all three packages with rpm -e --nodeps. The only file left behind was /etc/gnucash/environment.rpmsave, though all three packages left behind some empty directories (mostly in /usr/lib/.build-id). I reinstalled gnucash and it’s working again!


That’s great to hear. Still not sure what caused it. I’d have thought all the dnf reinstalls etc. would’ve had the same effect, but clearly not.