gnucash-2.0.4-r1 don't compile with slib-3.1.1-r1 but the ebuild depends on. Reproducible: Always Steps to Reproduce: Actual Results: checking for (g-wrap) guile module... yes checking for (g-wrap gw-glib-spec) guile module... yes checking for SLIB support... configure: error: Cannot find SLIB. Are you sure you have it installed? See http://bugzilla.gnome.org/show_bug.cgi?id=347922 !!! Please attach the following file when filing a report to bugs.gentoo.org: !!! /var/tmp/portage/gnucash-2.0.4-r1/work/gnucash-2.0.4/config.log !!! ERROR: app-office/gnucash-2.0.4-r1 failed. Call stack: ebuild.sh, line 1546: Called dyn_compile ebuild.sh, line 937: Called src_compile gnucash-2.0.4-r1.ebuild, line 69: Called econf '--disable-debug' '--disable-ofx' '--disable-doxygen' '--disable-html-docs' '--disable-dot' '--enable-hbci' '--enable-mt940' '--enable-locale-specific-tax' ebuild.sh, line 540: Called die !!! econf failed !!! If you need support, post the topmost build error, and the call stack if relevant.
Daniel, Please re-emerge slib and try again?
It works. Thanks
*** Bug 165318 has been marked as a duplicate of this bug. ***
Solution is to remerge slib (which is what the bump was for, so that is strange).
Re-emerging fixed configure for me. Now having compile problem; see bug #165418 Isn't all this linked to bug #143012 and blocking bug #163921 ?
Remerging slib doesn't work for me. gnucash tries to downgrade slib from 3.1.4-r2 to 3.1.1-r1. I still get the error detailed in the OP.
James, slib-3.1.4 needs to be masked locally
(In reply to comment #7) > James, slib-3.1.4 needs to be masked locally > Yeah, I just did that, and it seems to be building now. guile seems to be involved somehow too. I'll try to isolate the dependency issue, and post my findings when I figure it out.
(In reply to comment #8) > (In reply to comment #7) > > James, slib-3.1.4 needs to be masked locally > > > > Yeah, I just did that, and it seems to be building now. guile seems to be > involved somehow too. I'll try to isolate the dependency issue, and post my > findings when I figure it out. > I originally didn't have slib 3.1.4 masked, and it pulled in ~amd64 guile. When I masked slib 3.1.4, guile got recompiled back down to amd64, and now gnucash builds with no problems. Before doing this, slib 3.1.1 wasn't detected by the configure script, even if I manually recompiled it. I believe therefore that guile was to blame, and remerging guile fixed the problem. No idea how it got messed up in the first place though. Next, I unmerged gnucash and its unique dependencies, and removed the mask on slib 3.1.4. When I emerged gnucash again, it pulled in 3.1.1 and built correctly, without any 3.1.4 dependency issues. I'll keep trying to reproduce the bug, but I suspect that it was probably just a stale configuration file belonging to guile.
(In reply to comment #9) > I originally didn't have slib 3.1.4 masked, and it pulled in ~amd64 guile. When > I masked slib 3.1.4, guile got recompiled back down to amd64, and now gnucash > builds with no problems. This can be fixed locally by filling /etc/portage/package.keywords or /etc/portage/package.use (not sure whuich one). This will allow you to specify x86 amd64 or ~<foo> for specific packages, if thats your problem. > I'll keep trying to reproduce the bug, but I suspect that it was probably just > a stale configuration file belonging to guile. I can easily reproduce the bug.
(In reply to comment #10) > > I can easily reproduce the bug. > I meant the configure bug, not the compile bug in bug #165418.
(In reply to comment #11) in page dealing with bug 164974, I speak about bug 164974: I do can reproduce easily 164974 configure problem.
*** Bug 167425 has been marked as a duplicate of this bug. ***
*** Bug 168184 has been marked as a duplicate of this bug. ***
*** Bug 171542 has been marked as a duplicate of this bug. ***
*** Bug 172591 has been marked as a duplicate of this bug. ***
*** Bug 172625 has been marked as a duplicate of this bug. ***
*** Bug 172806 has been marked as a duplicate of this bug. ***
*** Bug 172833 has been marked as a duplicate of this bug. ***
*** Bug 172910 has been marked as a duplicate of this bug. ***
After various recompilations I've finally managed to get things to compile again. It seems that g-wrap -> guile -> slib -> gnucash worked for me. This whole upgrade path certainly isn't ideal, and I'm a bit surprised to see that this bug is closed. With people upgrading slib-3.1.1-r1 gnucash may easily break for them.
*** Bug 172960 has been marked as a duplicate of this bug. ***
(In reply to comment #21) > After various recompilations I've finally managed to get things to compile > again. It seems that g-wrap -> guile -> slib -> gnucash worked for me. > > This whole upgrade path certainly isn't ideal, and I'm a bit surprised to see > that this bug is closed. With people upgrading slib-3.1.1-r1 gnucash may easily > break for them. After running into the same configuration issue, I found this comment and tried: #emerge guile slib gnucash Which fixed the issue for me: checking for SLIB support... yes Anyone know what the root cause is? I agree with Hans de Graaff -- why is this marked as closed without at least communicating the fix to the user?
the fix to this issue is to re-emerge slib and for a related issue to re-emerge g-wrap. I guess there could be an einfo message explaining that on the gnucash ebuild.
*** Bug 173490 has been marked as a duplicate of this bug. ***
My initial problems where caused by emerging slib, so I don't think re-emerging it once more would have solved the problem. In any case some einfo stuff would be great. It seems like this is going to be hard to resolve automatically so at least users should be told what to expect and do. Isn't it possible to use some careful version bumping and dependencies to get users to upgrade everything in the right order?
*** Bug 173809 has been marked as a duplicate of this bug. ***
*** Bug 175069 has been marked as a duplicate of this bug. ***
*** Bug 184562 has been marked as a duplicate of this bug. ***
*** Bug 186088 has been marked as a duplicate of this bug. ***
*** Bug 176344 has been marked as a duplicate of this bug. ***
