After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 731889 - guile 2 exports different autoconf macros than what is expected
guile 2 exports different autoconf macros than what is expected
Status: RESOLVED FIXED
Product: GnuCash
Classification: Other
Component: Build system
git-master
Other Linux
: Normal major
: ---
Assigned To: gnucash-core-maint
gnucash-core-maint
: 733425 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2014-06-19 00:10 UTC by Muhammet Kara
Modified: 2018-06-29 23:31 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Terminal output of ./configure for GnuCash (9.69 KB, text/plain)
2014-06-19 00:10 UTC, Muhammet Kara
  Details
config.log for GnuCash (87.09 KB, text/plain)
2014-06-19 01:49 UTC, Muhammet Kara
  Details
config.log of Anjuta Project for GnuCash (114.25 KB, text/x-log)
2014-06-19 10:36 UTC, Muhammet Kara
  Details
Build a local interpreter instead of trying to find the one which matches what pkg-config found. (5.35 KB, patch)
2015-01-29 21:52 UTC, John Ralls
committed Details | Review

Description Muhammet Kara 2014-06-19 00:10:51 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
Comment 1 John Ralls 2014-06-19 01:20:16 UTC
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.
Comment 2 Muhammet Kara 2014-06-19 01:48:09 UTC
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.)
Comment 3 Muhammet Kara 2014-06-19 01:49:15 UTC
Created attachment 278727 [details]
config.log for GnuCash
Comment 4 John Ralls 2014-06-19 03:58:08 UTC
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?
Comment 5 Geert Janssens 2014-06-19 08:01:41 UTC
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 ?
Comment 6 Muhammet Kara 2014-06-19 10:33:36 UTC
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.
Comment 7 Muhammet Kara 2014-06-19 10:36:00 UTC
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.
Comment 8 Geert Janssens 2014-06-19 12:44:50 UTC
(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 ?
Comment 9 Muhammet Kara 2014-06-19 19:50:33 UTC
(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.
Comment 10 Geert Janssens 2014-06-28 14:23:05 UTC
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.
Comment 11 Geert Janssens 2014-07-04 10:13:02 UTC
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.
Comment 12 John Ralls 2014-07-19 22:22:47 UTC
*** Bug 733425 has been marked as a duplicate of this bug. ***
Comment 13 Andrew Schein 2014-07-20 15:42:54 UTC
I have reproduced this behaviour on Ubuntu 14.04.
Comment 14 Geert Janssens 2015-01-24 15:16:18 UTC
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.
Comment 15 John Ralls 2015-01-29 21:52:07 UTC
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.
Comment 16 Geert Janssens 2015-01-30 11:22:07 UTC
(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
Comment 17 John Ralls 2015-01-30 15:30:40 UTC
(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.
Comment 18 Geert Janssens 2015-01-30 21:36:42 UTC
(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...
Comment 19 John Ralls 2015-01-31 01:02:19 UTC
(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.
Comment 20 Geert Janssens 2015-01-31 07:31:08 UTC
(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.
Comment 21 Geert Janssens 2015-01-31 07:47:10 UTC
(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).
Comment 22 Geert Janssens 2015-01-31 12:40:15 UTC
(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.
Comment 23 Geert Janssens 2015-01-31 13:37:26 UTC
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.
Comment 24 John Ralls 2018-06-29 23:31:22 UTC
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.