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
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:
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.
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).
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.
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:
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!