GNOME Bugzilla – Bug 731889
guile 2 exports different autoconf macros than what is expected
Last modified: 2018-06-29 23:31:22 UTC
Created attachment 278725 [details] Terminal output of ./configure for GnuCash When I try to build gnucash from git-master, it gives this error: configure: error: guile 2 is found on your system, but appears to export different autoconf macros than what we expected. Please report this as a bug in GnuCash, so we can fix this for your platform. How to reproduce: $ git clone https://github.com/Gnucash/gnucash.git $ cd gnucash/ $ ./autogen.sh $ ./configure
What distro? Are you using the Guile2 that came with it or one you built from source? If the latter, what version and what configure options did you pass to it? Please attach config.log as well.
Sorry for the missing info. Distro: Fedora 20 X86_64 I was using the Guile2 came with the distro. After getting this error, I imported the project into anjuta, then it was built successfully by Anjuta. (Anjuta asked for a few more packages to be installed, I don't know why.)
Created attachment 278727 [details] config.log for GnuCash
Interesting. Apparently it has something to do with defining GUILE_PROGS. Geert, you use F20 and haven't had any problems (obviously, you would have fixed them if you had). Any thoughts on why Muhammet is getting a different result?
Indeed I'm on exactly the same platform and never ran into this. GUILE_PROGS is defined in /usr/share/aclocal/guile.m4 on my system and that file is part of the guile-devel.rpm package. That's the same package the provides guile-2.0.pc. So if package-config properly detects GUILE_CFLAGS and GUILE_LIBS then the GUILE_PROGS macro should be there as well. Muhammet: do you remember which packages anjuta asked you to install ?
Unfortunately, I can't remember exactly. But by checking the terminal's history, I think they might be: swig*, libdbi*, libgnomecanvas*, *goffice*, and webkit*. I installed all packages which came up by putting those star characters.
Created attachment 278753 [details] config.log of Anjuta Project for GnuCash And here is the config.log from Anjuta's project folder, which was built and installed successfully.
(In reply to comment #6) > Unfortunately, I can't remember exactly. But by checking the terminal's > history, I think they might be: swig*, libdbi*, libgnomecanvas*, *goffice*, and > webkit*. > > I installed all packages which came up by putting those star characters. By themselves these look like unrelated, but perhaps one of these has pulled in an additional dependency that makes the difference. Can you use yum history to figure out exactly what got installed ? Also, now that the additional dependencies have been installed, does the autogen.sh/configure/make cycle work without importing it into anjuta ?
(In reply to comment #8) > (In reply to comment #6) > > Unfortunately, I can't remember exactly. But by checking the terminal's > > history, I think they might be: swig*, libdbi*, libgnomecanvas*, *goffice*, and > > webkit*. > > > > I installed all packages which came up by putting those star characters. > > By themselves these look like unrelated, but perhaps one of these has pulled in > an additional dependency that makes the difference. > > Can you use yum history to figure out exactly what got installed ? > > Also, now that the additional dependencies have been installed, does the > autogen.sh/configure/make cycle work without importing it into anjuta ? Here is the list of packages which were installed with those commands, gathered from yum history: swig-2.0.11-1.fc20.x86_64 @fedora libdbi-devel-0.8.4-4.fc20.x86_64 libdbi-dbd-mysql-0.8.3-13.fc20.x86_64 libdbi-dbd-pgsql-0.8.3-13.fc20.x86_64 libdbi-dbd-sqlite-0.8.3-13.fc20.x86_64 libdbi-drivers-0.8.3-13.fc20.x86_64 mariadb-libs-1:5.5.37-1.fc20.x86_64 postgresql-libs-9.3.4-1.fc20.x86_64 libgnomecanvas-devel-2.30.3-7.fc20.x86_64 goffice-0.10.16-1.fc20.x86_64 ORBit2-devel-2.14.19-9.fc20.x86_64 gnome-vfs2-devel-2.24.4-14.fc20.x86_64 goffice-devel-0.10.16-1.fc20.x86_64 goffice08-devel-0.8.17-10.fc20.x86_64 indent-2.2.11-12.fc20.x86_64 libIDL-devel-0.8.14-7.fc20.x86_64 libbonobo-devel-2.32.1-6.fc20.x86_64 libbonoboui-devel-2.24.5-6.fc20.x86_64 libglade2-devel-2.6.4-10.fc20.x86_64 libgnome-devel-2.32.1-7.fc20.x86_64 libgnomeui-devel-2.24.5-7.fc20.x86_64 libgsf-devel-1.14.29-1.fc20.x86_64 popt-devel-1.16-2.fc20.x86_64 webkitgtk-devel-2.2.7-1.fc20.x86_64 webkitgtk-doc-2.2.7-1.fc20.noarch Yes, autogen.sh/configure/make cycle works now without importing into anjuta.
Well, I looked at this from all sides, but I honestly can't find any reason in the code why this wasn't working. The configure runs files have identical results up until the GUILE_PROGS check. There is a slight shift in configure line-numbers on all lines (4-8 lines of difference). I have no idea whether that is relevant or not. Since you got it working I will close this report as not a GnuCash bug for now. Should other reports come in for the same issue, we may have to dig deeper. For now we better spend our time on more pressing matters.
Today I ran into this myself while configuring a new laptop and so I had a chance to dig a bit deeper. The issue appeared to be that if you install guile-devel you should rerun autogen.sh. But this reveals a flaw in our guile detection logic. guile-devel should be installed before autogen.sh is run so we probably have to test for it in autogen.sh already. Or at least improve the messaging in configure.
*** Bug 733425 has been marked as a duplicate of this bug. ***
I have reproduced this behaviour on Ubuntu 14.04.
Coming back to this bug I think the biggest issue here is the poorly chosen error message. In most cases the solution is simply to rerun autogen.sh and no changes on behalf of the gnucash development team needed. So I have changed the message to reflect that.
Created attachment 295781 [details] [review] Build a local interpreter instead of trying to find the one which matches what pkg-config found. I'm a bit nervous about one aspect of this: The only way I could get gnc-test-env to find gnc-guile was to use `pwd` in configure. That depends $top-builddir being the directory from which configure is run. I *think* that's correct, but I worry that there's some way to make that not be the case. This still searches $PATH for guild if gnc_has_guile_2 is true, which isn't a problem now but might be once guile-2.2 ships.
(In reply to comment #15) > Created an attachment (id=295781) [details] [review] > Build a local interpreter instead of trying to find the one which matches what > pkg-config found. > Nice work. It's missing one dependency on my system though: make[2]: Entering directory `/kobaltnet/janssege/Development/Builds/gnucash-f20-master' gcc -DHAVE_CONFIG_H -I. -I/kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git -pthread -I/usr/include/guile/2.0 -g -g -MT gnc_guile-guile.o -MD -MP -MF .deps/gnc_guile-guile.Tpo -c -o gnc_guile-guile.o `test -f 'util/guile.c' || echo '/kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git/'`util/guile.c rm -f make-gnucash-potfiles.tmp sed < /kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git/make-gnucash-potfiles.in > make-gnucash-potfiles.tmp \ -e 's:@-SRCDIR-@:/kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git:g' \ -e 's:@-PERL-@:/usr/bin/perl:g' chmod +x make-gnucash-potfiles.tmp mv make-gnucash-potfiles.tmp make-gnucash-potfiles /kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git/util/guile.c:37:18: fatal error: ltdl.h: No such file or directory #include <ltdl.h> ^ compilation terminated. make[2]: *** [gnc_guile-guile.o] Error 1 make[2]: Leaving directory `/kobaltnet/janssege/Development/Builds/gnucash-f20-master' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/kobaltnet/janssege/Development/Builds/gnucash-f20-master' make: *** [all] Error 2 That is after autogen.sh and rerunning configure. > I'm a bit nervous about one aspect of this: The only way I could get > gnc-test-env to find gnc-guile was to use `pwd` in configure. That depends > $top-builddir being the directory from which configure is run. I *think* that's > correct, but I worry that there's some way to make that not be the case. > Don't worry about that part. While you were working on this local guile interpreter I rewrote gnc-test-env in perl yesterday but didn't have time to discuss it yet. So for gnc-test-env this is no longer an issue. > This still searches $PATH for guild if gnc_has_guile_2 is true, which isn't a > problem now but might be once guile-2.2 ships. That should be ok for now especially since guile does the same thing in its m4 macros. A more general question: do we want to apply this on maint ? The current implementation in stable can lead to bad things happening as you wrote on irc. So I'm tempted to say yes. And what about the rewrite of gnc-test-env in perl? If you worry about the use of `pwd` then the new perl based gnc-test-env should be reassuring. The script is quite simple and make distcheck passes fine. For completeness, I have also rewritten iso-currencies-to-c to use xml/xsl instead of a guile script. Ready to push, just need to know which branch. If we expect changes to currencies between now and the release of 2.8, it would be a source of merge conflicts if it was only pushed to master. It should be pretty safe to apply to maint: the source file generated via xml/xsl only differs in these aspects from the one generated via the scheme: - new file includes a comment header - some whitespace changes - the scheme version contained invalid utf8 characters for several symbols
(In reply to comment #16) [SNIP] > Nice work. It's missing one dependency on my system though: > /kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git/util/guile.c:37:18: > fatal error: ltdl.h: No such file or directory > #include <ltdl.h> That's libtool's header. It seems odd to me that that could be missing when all of the other libtool requirements are satisfied and odder still that I didn't have any problem on F21. [SNIP] > I rewrote gnc-test-env in perl yesterday Excellent! > > problem now but might be once guile-2.2 ships. > > That should be ok for now especially since guile does the same thing in its m4 > macros. Right. But as soon as 2.2 ships Red Hat will munge the name for either guild-2.0 or guild-2.2 (and if 1.8 is any guide, screw it up) and we'll have to figure out a work-around. > > > A more general question: do we want to apply this on maint ? The current > implementation in stable can lead to bad things happening as you wrote on irc. > So I'm tempted to say yes. > > And what about the rewrite of gnc-test-env in perl? If you worry about the use > of `pwd` then the new perl based gnc-test-env should be reassuring. The script > is quite simple and make distcheck passes fine. > > For completeness, I have also rewritten iso-currencies-to-c to use xml/xsl > instead of a guile script. Ready to push, just need to know which branch. If we > expect changes to currencies between now and the release of 2.8, it would be a > source of merge conflicts if it was only pushed to master. It should be pretty > safe to apply to maint: the source file generated via xml/xsl only differs in > these aspects from the one generated via the scheme: > - new file includes a comment header > - some whitespace changes > - the scheme version contained invalid utf8 characters for several symbols I'm inclined to do all of this in maint. The bad characters in iso-currencies is a serious problem for Indians and needs to be fixed, and XSL is a much more appropriate tool than Scheme for that. Perl is also better than Scheme for generating the test environment, but Shell would be better still if it's feasible. Another place we can whack Scheme is intl-scm/xgettext.scm. That's now built into gettext as of 1.18, which has been out for several years now.
(In reply to comment #17) > (In reply to comment #16) > [SNIP] > > Nice work. It's missing one dependency on my system though: > > /kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git/util/guile.c:37:18: > > fatal error: ltdl.h: No such file or directory > > #include <ltdl.h> > > That's libtool's header. It seems odd to me that that could be missing when all > of the other libtool requirements are satisfied and odder still that I didn't > have any problem on F21. > > [SNIP] > > I rewrote gnc-test-env in perl yesterday > > Excellent! > > > > problem now but might be once guile-2.2 ships. > > > > That should be ok for now especially since guile does the same thing in its m4 > > macros. > > Right. But as soon as 2.2 ships Red Hat will munge the name for either > guild-2.0 or guild-2.2 (and if 1.8 is any guide, screw it up) and we'll have to > figure out a work-around. > > > > > > > A more general question: do we want to apply this on maint ? The current > > implementation in stable can lead to bad things happening as you wrote on irc. > > So I'm tempted to say yes. > > > > And what about the rewrite of gnc-test-env in perl? If you worry about the use > > of `pwd` then the new perl based gnc-test-env should be reassuring. The script > > is quite simple and make distcheck passes fine. > > > > For completeness, I have also rewritten iso-currencies-to-c to use xml/xsl > > instead of a guile script. Ready to push, just need to know which branch. If we > > expect changes to currencies between now and the release of 2.8, it would be a > > source of merge conflicts if it was only pushed to master. It should be pretty > > safe to apply to maint: the source file generated via xml/xsl only differs in > > these aspects from the one generated via the scheme: > > - new file includes a comment header > > - some whitespace changes > > - the scheme version contained invalid utf8 characters for several symbols > > I'm inclined to do all of this in maint. The bad characters in iso-currencies > is a serious problem for Indians and needs to be fixed, and XSL is a much more > appropriate tool than Scheme for that. Perl is also better than Scheme for > generating the test environment, but Shell would be better still if it's > feasible. The perl script is extremely short and efficient imo. Shell would require more work. We have perl available at build time on all platforms we support. > Another place we can whack Scheme is intl-scm/xgettext.scm. That's > now built into gettext as of 1.18, which has been out for several years now. That's next on my list...
(In reply to comment #18) > The perl script is extremely short and efficient imo. Shell would require more > work. We have perl available at build time on all platforms we support. OK, no problem. > > > Another place we can whack Scheme is intl-scm/xgettext.scm. That's > > now built into gettext as of 1.18, which has been out for several years now. > That's next on my list... I think we can just nuke it and move the scheme files from POTFILES.skip to POTFILES.in.
(In reply to comment #17) > (In reply to comment #16) > [SNIP] > > Nice work. It's missing one dependency on my system though: > > /kobaltnet/janssege/Development/EclipseGnuCash/GnuCash-git/util/guile.c:37:18: > > fatal error: ltdl.h: No such file or directory > > #include <ltdl.h> > > That's libtool's header. It seems odd to me that that could be missing when all > of the other libtool requirements are satisfied and odder still that I didn't > have any problem on F21. > It's missing on my system because I didn't have the libtool-ltdl-devel package installed on my system. I didn't need it until now. The runtime components have been enough. No doubt others will trip over this as well. Is there a way configure can check for this -devel package ? Or just for the header file and suggest to install the proper -dev/-devel package if not found.
(In reply to comment #19) > (In reply to comment #18) > > > Another place we can whack Scheme is intl-scm/xgettext.scm. That's > > > now built into gettext as of 1.18, which has been out for several years now. > > That's next on my list... > > I think we can just nuke it and move the scheme files from POTFILES.skip to > POTFILES.in. See bug 619899 for more on this. Aside from gettext we were waiting for the proper support in intltool. This support landed in intltool-0.50 which was released in October 2011 (3+ years now). I was waiting for this new release of intltool to trickle down in most distributions we care about before finishing up the last details on that bug. Is 3+ years sufficiently long ? RHEL6 is still on version 0.41 and probably will be forever. Debian wheezy has upgraded to version 0.50 meanwhile. So I think the time is right to finish this part. If you agree I'll go ahead and do so (on maint).
(In reply to comment #21) > If you agree I'll go ahead and do so (on maint). I have considered this some more and even RHEL7 ships intltool 0.50. So I decided the time is right and have pushed the necessary changes to drop the xgettext.scm machinery.
I went ahead and added the check for ltdl.h to configure. I have pushed your patch and my followup commit. That should be sufficient to consider this bug as fixed. Thanks for your input John.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=731889. Please update any external references or bookmarks.