GNOME Bugzilla – Bug 788191
swig files included in source distribution incompatible with guile 1
Last modified: 2018-06-29 23:59:51 UTC
Hi, While updating the FreeBSD port to the latest version I got a few errors testing the build. The FreeBSD ports by default uses guile version 1. guile 2 is available as an option. The generated files (For example swig-core-utils-guile.c) include undefined symbols for guile 1. I got the following warnings and errors: libtool: compile: cc [...] -c swig-gnc-module.c -fPIC -DPIC -o .libs/swig-gnc-module.o swig-gnc-module.c:895:14: warning: implicit declaration of function 'SCM_POINTER_P' is invalid in C99 [-Wimplicit-function-declaration] } else if (SCM_POINTER_P(s)) { ^ swig-gnc-module.c:896:15: warning: implicit declaration of function 'SCM_POINTER_VALUE' is invalid in C99 [-Wimplicit-function-declaration] *result = SCM_POINTER_VALUE(s); ^ swig-gnc-module.c:896:13: warning: incompatible integer to pointer conversion assigning to 'void *' from 'int' [-Wint-conversion] *result = SCM_POINTER_VALUE(s); ^ ~~~~~~~~~~~~~~~~~~~~ mv -f .deps/gnc-module.Tpo .deps/gnc-module.Plo 3 warnings generated. [...] libtool: link: cc [...] -o .libs/test-engine [..] ../../../src/gnc-module/.libs/libgnc-module.so: undefined reference to `SCM_POINTER_P' ../../../src/gnc-module/.libs/libgnc-module.so: undefined reference to `SCM_POINTER_VALUE' cc: error: linker command failed with exit code 1 (use -v to see invocation) Performing a diff from the previous version source distribution it looks like the files have been generated with a different swig version, which adds an "else if" stanza in a conditional containing the offending symbols. I have worked around that by removing that stanza, which I know isn't the best solution. I think that, if guile 1 compatibility is meant to be maintained, the distribution should be regenerated with compatible swig files. Thanks in advance for any help! NOTE: I included only essential log parts, but if needed I can send full build logs, please indicate preferred method, files are a little big.
Thanks for reporting this. I have searched a bit on the net and it appears to be due to a change in swig: https://github.com/swig/swig/pull/744/files That PR is responsible for the situation where guile bindings generated in an environment that uses guile 2 no longer work in an environment that uses guile 1. The only workaround currently is to generate the distribution tarballs in an environment using guile 1.8 still. As a side note: we have been discussing to drop guile 1 support for the upcoming gnucash 2.8 series as the maintenance for this guile version is popping up more and more issues like this one. So while we may fix this for the 2.6 series still (as that series did support guile 1.8), you may want to start thinking of getting gnucash to work with guile 2 on FreeBSD. There is no final decision yet, but I did want to point your attention to it.
Re-spun tarballs have been uploaded to SourceForge and Github and the links on www.gnucash.org have been updated.
A follow up on the swig issue: what I describe in comment 1 is true for swig 3.0.11. It has been fixed already in swig 3.0.12. The bad tarballs happened to be created with swig 3.0.11.
(In reply to Geert Janssens from comment #1) > Thanks for reporting this. > > I have searched a bit on the net and it appears to be due to a change in > swig: > https://github.com/swig/swig/pull/744/files > > That PR is responsible for the situation where guile bindings generated in > an environment that uses guile 2 no longer work in an environment that uses > guile 1. > > The only workaround currently is to generate the distribution tarballs in an > environment using guile 1.8 still. > > As a side note: we have been discussing to drop guile 1 support for the > upcoming gnucash 2.8 series as the maintenance for this guile version is > popping up more and more issues like this one. So while we may fix this for > the 2.6 series still (as that series did support guile 1.8), you may want to > start thinking of getting gnucash to work with guile 2 on FreeBSD. There is > no final decision yet, but I did want to point your attention to it. As a followup to this, for the record. The asterisk port in the FreeBSD ports tree already has GUILE2 supports and works quite well when compiled with such option. I'm keeping the default at guile1 because depending on the guile 2 port is causing conflicts for users, forcing them to remove other software, if building everything with default. BTW recent additions to the FreeBSD ports system (flavours) can also be leveraged to avoid the problem described above, and I plan to take advantage of this as soon as that's possible.
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=788191. Please update any external references or bookmarks.