GNOME Bugzilla – Bug 784428
Compilation error: minor-version
Last modified: 2017-12-08 16:38:54 UTC
On (trying to) compile, I get error: /usr/local/projects/git/pygobject/configure: line 2220: syntax error near unexpected token `minor-version' /usr/local/projects/git/pygobject/configure: line 2220: `AX_IS_RELEASE(minor-version)' Checking in configure.ac I found: AX_IS_RELEASE([minor-version]) While version are defined as: m4_define(pygobject_major_version, 3) m4_define(pygobject_minor_version, 25) m4_define(pygobject_micro_version, 2) I'm not an autotools expert, is this correct? Compilation stops immediately after)
I think you are missing autoconf-archive.
I cloned the Git repo directly, so I suspect I have all the files. This is the autogen.sh output: $ ./autogen.sh *** WARNING: I am going to run 'configure' with no arguments. *** If you wish to pass any to it, please specify them on the *** './autogen.sh' command line. aclocal: installing 'm4/glib-2.0.m4' from '/usr/share/aclocal/glib-2.0.m4' aclocal: installing 'm4/libtool.m4' from '/usr/share/aclocal/libtool.m4' aclocal: installing 'm4/ltoptions.m4' from '/usr/share/aclocal/ltoptions.m4' aclocal: installing 'm4/ltsugar.m4' from '/usr/share/aclocal/ltsugar.m4' aclocal: installing 'm4/ltversion.m4' from '/usr/share/aclocal/ltversion.m4' aclocal: installing 'm4/lt~obsolete.m4' from '/usr/share/aclocal/lt~obsolete.m4' aclocal: installing 'm4/pkg.m4' from '/usr/share/aclocal/pkg.m4' autoreconf: Entering directory `.' autoreconf: configure.ac: not using Gettext autoreconf: running: aclocal --force autoreconf: configure.ac: tracing autoreconf: running: libtoolize --copy --force libtoolize: putting auxiliary files in `.'. libtoolize: copying file `./ltmain.sh' libtoolize: putting macros in AC_CONFIG_MACRO_DIR, `m4'. libtoolize: copying file `m4/libtool.m4' libtoolize: copying file `m4/ltoptions.m4' libtoolize: copying file `m4/ltsugar.m4' libtoolize: copying file `m4/ltversion.m4' libtoolize: copying file `m4/lt~obsolete.m4' libtoolize: Consider adding `-I m4' to ACLOCAL_AMFLAGS in Makefile.am. autoreconf: running: /usr/bin/autoconf --force autoreconf: running: /usr/bin/autoheader --force autoreconf: running: automake --add-missing --copy --force-missing configure.ac:75: installing './compile' configure.ac:48: installing './config.guess' configure.ac:48: installing './config.sub' configure.ac:46: installing './install-sh' configure.ac:46: installing './missing' Makefile.am:55: installing './py-compile' gi/Makefile.am: installing './depcomp' tests/Makefile.am:30: warning: source file '$(srcdir)/gimarshallingtestsextra.c' is in a subdirectory, tests/Makefile.am:30: but option 'subdir-objects' is disabled automake: warning: possible forward-incompatibility. automake: At least a source file is in a subdirectory, but the 'subdir-objects' automake: automake option hasn't been enabled. For now, the corresponding output automake: object file(s) will be placed in the top-level directory. However, automake: this behaviour will change in future Automake versions: they will automake: unconditionally cause object files to be placed in the same subdirectory automake: of the corresponding sources. automake: You are advised to start using 'subdir-objects' option throughout your automake: project, to avoid future incompatibilities. tests/Makefile.am:26: warning: source file '$(GI_DATADIR)/tests/gimarshallingtests.c' is in a subdirectory, tests/Makefile.am:26: but option 'subdir-objects' is disabled tests/Makefile.am:55: warning: source file '$(GI_DATADIR)/tests/regress.c' is in a subdirectory, tests/Makefile.am:55: but option 'subdir-objects' is disabled autoreconf: Leaving directory `.' ./configure: line 2220: syntax error near unexpected token `minor-version' ./configure: line 2220: `AX_IS_RELEASE(minor-version)'
(In reply to John from comment #2) > I cloned the Git repo directly, so I suspect I have all the files. Dude, what kind of reasoning is that? Try passing the equivalent of build-dep as in sudo apt-get install build-dep <package name> to your package manger. If autoconf-archive still didn't install, install the package individually. This isn't a problem on GNOME's side. I know what you're thinking, "Shouldn't the configure script display atuoconf-archive as a missing dependency?" Sadly no. Apparently, it's impossible due to the way the autotool macro system is designed.
> Dude, what kind of reasoning is that? Thanks for the reply. I had no idea that the reference to autoconf-archive was a reference to a separate software package, and I apologize for my ignorance. Though I routinely compile probably hundreds of packages per year, and have been doing so for 20+ years, I have never heard a mention of autoconf-archive (or gnulib-tool), and certainly never needed it. Which makes me suspect that it is not as commonly used as some of the references I found seem to suggest. In fact, it is not included in the development tools of Slackware. I did find it as an extra package in slackbuilds.org. From what I have read until now, I'm not sure I would ever want to use it myself, as it seems to require everyone else who wants to compile my programs to also install autoconf-archive. Anyway, I have no intention to start a flame war. I would like to humbly suggest however to include some kind of warning that the project uses autoconf-archive. Though I'm certainly not a professional software developer, I can imagine others experiencing the same problem. BTW, if "syntax error near unexpected token `minor-version'" is an indication of autoconf-archive missing, why not add a note to the error message - say 'Do you have autoconf-archive installed?' ?
Scott, please try to be a bit friendlier and assume good intentions, this isn't helpful. John, we have moved from gnome-common to autconf-archive with 3.25.1 (following the migration guide here [0]). If you take the release tarball and use configure it shouldn't be needed, as all the required macros are included there. Only if you use autogen.sh or when using a git checkout do we require it. I agree that the current error message in case it is missing is confusing and not helpful and that it should be improved if possible. [0] https://wiki.gnome.org/Projects/GnomeCommon/Migration
(In reply to Christoph Reiter (lazka) from comment #5) > Scott, please try to be a bit friendlier and assume good intentions, this > isn't helpful. I'm sorry, I misunderstood the context of the statement. I will try to build a healthier atmosphere in the future.
Thanks, Christoph! I found a package for 3.25.1 on the gnome ftp site - which I suspect was already prepared with the gnulib-tool and autoconf-archive. It installed without any problem. I then found out that installing py3cairo didn't update pkgconfig's py3cairo.pc file, which had remained on 1.10.something, even though cairo.version (in Python3) reported 1.13.3. This didn't let me compile pygobject. After editing the .pc file compilation went well. This entire exercise is to try and get pycairo's matrices working. I've written a small graphics program which needs some transforms (translate and scale) on an image. I've tried to understand pygi_foreign_cairo.c, but it seems somewhat of an exception as all other elements (Context, Surface, etc) use pointers. The work/reading I'd need (done some of it already) to get up-to-speed on pygobject, pycairo etc, seems a bit excessive - I can more easily convert the coordinates myself. On the other hand, it would be nice to have Matrices working in GooCanvas. (There's a bug open since 2011 or so)
(In reply to John from comment #7) > Thanks, Christoph! > > I found a package for 3.25.1 on the gnome ftp site - which I suspect was > already prepared with the gnulib-tool and autoconf-archive. It installed > without any problem. Good! > I then found out that installing py3cairo didn't update pkgconfig's > py3cairo.pc file, which had remained on 1.10.something, even though > cairo.version (in Python3) reported 1.13.3. This didn't let me compile > pygobject. After editing the .pc file compilation went well. Weird, did you install the new pycairo directly using setup.py? Might be that it uses a different default installation prefix and it ended up somewhere else (setup.py and distro packaging don't mix well..) > This entire exercise is to try and get pycairo's matrices working. I've > written a small graphics program which needs some transforms (translate and > scale) on an image. I've tried to understand pygi_foreign_cairo.c, but it > seems somewhat of an exception as all other elements (Context, Surface, etc) > use pointers. Yeah, the matrix type is a bit different compared to the other ones, as it's not ref counted and stack allocated. The foreign interface might need adjustment, but I haven't looked. > The work/reading I'd need (done some of it already) to get up-to-speed on > pygobject, pycairo etc, seems a bit excessive - I can more easily convert > the coordinates myself. On the other hand, it would be nice to have Matrices > working in GooCanvas. (There's a bug open since 2011 or so) I assume you mean bug 651043
> Weird, did you install the new pycairo directly using setup.py? Might be that > it uses a different default installation prefix and it ended up somewhere > else (setup.py and distro packaging don't mix well..) Hello Christoph, I very rarely install python modules using the Slackware packaging system (or via Slackbuilds.org) I've used 'python3 setup.py install' for pycairo. I did suspect possible problems with install paths, but I looked for and didn't find any duplicate or wrongly installed .pc files. > Yeah, the matrix type is a bit different compared to the other ones, as it's > not ref counted and stack allocated. The foreign interface might need > adjustment, but I haven't looked. I've never touched anything from the interfaces, but as far as I can determine, there is no interface defined for cairo.Matrix at all. Also confirmed by bug 651043.
*** Bug 791182 has been marked as a duplicate of this bug. ***
Created attachment 365246 [details] [review] configure.ac: Error out in case autoconf-archive isn't installed