GNOME Bugzilla – Bug 558017
Build failure due to some perl macro
Last modified: 2009-09-21 21:53:42 UTC
I'm building directly from svn using jhbuild which terminates with: ./configure: line 20624: syntax error near unexpected token `5.6.0' ./configure: line 20624: `GLIBMM_CHECK_PERL(5.6.0)' + exit 1
Does it help to change this to GLIBMM_CHECK_PERL([5.6.0]) ? I don't understand it, but I've seen that in another module.
It doesn't help. And this is the lines at 20624 in configure: # This macro is installed by glibmm # Doxygen needs the path to the installed perl. GLIBMM_CHECK_PERL(5.6.0) So the macro isn't even expanded afaict.
Unfortunately, I can't reproduce this so it's hard for me to fix.
What distro are you using? This doesn't seem to be a widespread problem.
Please respond.
Ubuntu 8.04. I still get the exact same problem. There seem to be something weird happening when automake --add-missing is run that I missed before: + automake --add-missing configure.in:62: installing `scripts/install-sh' configure.in:62: installing `scripts/missing' Makefile.am: installing `./INSTALL' build_shared/Makefile_build.am_fragment:15: shell echo $(sublib_name: non-POSIX variable name build_shared/Makefile_build.am_fragment:15: (probably a GNU make extension) atk/atkmm/Makefile.am:24: `build_shared/Makefile_build.am_fragment' included from here build_shared/Makefile_build.am_fragment:44: strip $(all_includes: non-POSIX variable name build_shared/Makefile_build.am_fragment:44: (probably a GNU make extension) atk/atkmm/Makefile.am:24: `build_shared/Makefile_build.am_fragment' included from here atk/atkmm/Makefile.am: installing `scripts/depcomp' build_shared/Makefile_gensrc.am_fragment:49: `%'-style pattern rules are a GNU make extension atk/src/Makefile.am:10: `build_shared/Makefile_gensrc.am_fragment' included from here build_shared/Makefile_gensrc.am_fragment:50: notdir $*: non-POSIX variable name build_shared/Makefile_gensrc.am_fragment:50: (probably a GNU make extension) atk/src/Makefile.am:10: `build_shared/Makefile_gensrc.am_fragment' included from here build_shared/Makefile_gensrc.am_fragment:54: patsubst %.hg,$(sublib_srcdir: non-POSIX variable name build_shared/Makefile_gensrc.am_fragment:54: (probably a GNU make extension) atk/src/Makefile.am:10: `build_shared/Makefile_gensrc.am_fragment' included from here docs/reference/Makefile.am:73: <D: non-POSIX variable name docs/reference/Makefile.am:86: <D: non-POSIX variable name build_shared/Makefile_build.am_fragment:15: shell echo $(sublib_name: non-POSIX variable name build_shared/Makefile_build.am_fragment:15: (probably a GNU make extension) gdk/gdkmm/Makefile.am:24: `build_shared/Makefile_build.am_fragment' included from here build_shared/Makefile_build.am_fragment:44: strip $(all_includes: non-POSIX variable name build_shared/Makefile_build.am_fragment:44: (probably a GNU make extension) gdk/gdkmm/Makefile.am:24: `build_shared/Makefile_build.am_fragment' included from here build_shared/Makefile_gensrc.am_fragment:49: `%'-style pattern rules are a GNU make extension gdk/src/Makefile.am:10: `build_shared/Makefile_gensrc.am_fragment' included from here build_shared/Makefile_gensrc.am_fragment:50: notdir $*: non-POSIX variable name build_shared/Makefile_gensrc.am_fragment:50: (probably a GNU make extension) gdk/src/Makefile.am:10: `build_shared/Makefile_gensrc.am_fragment' included from here build_shared/Makefile_gensrc.am_fragment:54: patsubst %.hg,$(sublib_srcdir: non-POSIX variable name build_shared/Makefile_gensrc.am_fragment:54: (probably a GNU make extension) gdk/src/Makefile.am:10: `build_shared/Makefile_gensrc.am_fragment' included from here build_shared/Makefile_build.am_fragment:15: shell echo $(sublib_name: non-POSIX variable name build_shared/Makefile_build.am_fragment:15: (probably a GNU make extension) gtk/gtkmm/Makefile.am:30: `build_shared/Makefile_build.am_fragment' included from here build_shared/Makefile_build.am_fragment:44: strip $(all_includes: non-POSIX variable name build_shared/Makefile_build.am_fragment:44: (probably a GNU make extension) gtk/gtkmm/Makefile.am:30: `build_shared/Makefile_build.am_fragment' included from here build_shared/Makefile_gensrc.am_fragment:49: `%'-style pattern rules are a GNU make extension gtk/src/Makefile.am:10: `build_shared/Makefile_gensrc.am_fragment' included from here build_shared/Makefile_gensrc.am_fragment:50: notdir $*: non-POSIX variable name build_shared/Makefile_gensrc.am_fragment:50: (probably a GNU make extension) gtk/src/Makefile.am:10: `build_shared/Makefile_gensrc.am_fragment' included from here build_shared/Makefile_gensrc.am_fragment:54: patsubst %.hg,$(sublib_srcdir: non-POSIX variable name build_shared/Makefile_gensrc.am_fragment:54: (probably a GNU make extension) gtk/src/Makefile.am:10: `build_shared/Makefile_gensrc.am_fragment' included from here I have no idea if that is related to my problem or not.
I'm using Ubuntu 8.10 and used to use Ubuntu 8.04. Maybe it's just not finding the installed GLIBMM_CHECK_PERL glibmm m4 macro for some reason.
(In reply to comment #7) > Maybe it's just not finding the installed GLIBMM_CHECK_PERL glibmm m4 macro for > some reason. That's most likely the cause, yes. The macro in question is installed with glibmm, if that helps. The Automake warnings about non-POSIX constructs are not related.
FYI, I get the exact same build failure on a different machine with Ubuntu 9.04.
Could you check if that macro is installed?
Is this a jhbuild session? Are you using the system glibmm or did you build that from git as well? If you built glibmm yourself, it could be that the M4 file with the macro has been installed to a location where aclocal doesn't look for it by default. In that case, adding the necessary -I option to the ACLOCAL_FLAGS environment variable should help. For a quick test, just installing the distribution's glibmm development package should make it work, too.
*** Bug 590893 has been marked as a duplicate of this bug. ***
I can see the same on Ubuntu 9.04 when configuring within a jhbuild environment. glibmm failed to build. So it seems the macros are missing, and it should point that out.
You haven't done a "jhbuild bootstrap" by any chance? Don't.
(In reply to comment #14) > You haven't done a "jhbuild bootstrap" by any chance? Don't. I use jhbuild boostrap all the time and find that several things break if I don't. Please don't just handwave some random thing. Comment #10 is relevant. The file should be at, for instance, /opt/gnome228/share/aclocal/glibmm_check_perl.m4
I'm not hand-waving. If you do a jhbuild bootstrap without subsequently building glibmm within your jhbuild as well, it is quite likely that it will break because the aclocal installed by jhbuild knows zilch about your system's aclocal.
jhbuild boostrap is typically done right after a jhbuild installation, not after building glibmm.
Sure. What I mean is that you probably cannot use the system glibmm in that case, at least not without setting the aclocal include path explicitly. That's why I asked whether glibmm was built using jhbuild as well. Unfortunately we haven't got an answer to that question yet.
(In reply to comment #18) > Sure. What I mean is that you probably cannot use the system glibmm in that > case I don't think anyone is trying to use the system glibmm, so I don't see how this is relevant. If they are building gtkmm in jhbuild then they presumably built all its dependencies in gtkmm too. Since this bug was filed, I've built gtkmm in jhbuild in new Ubuntu Jaunty installs on new PCs. If I can't reproduce it then we need some more clues, such as whether the file is there, what's in it, and what the environment variables are. Note that this bug is about _gtkmm_ not building, but comment #13 mentinos _glibmm_ not building, which is not at all the same thing. glibmm has the m4 macro in its scripts directory and installs it for gtkmm to use later.
(In reply to comment #19) > If I can't reproduce it then we need some more clues, such > as whether the file is there, what's in it, and what the environment variables > are. I completely agree that we need more clues and changed the status to NEEDINFO for that reason.
I have not done a 'jhbuild bootstrap'. I use distro stuff if possible. in comment #13 I wanted to point out the glibmm failed to build (Bug 590907 by the way) and that I had the feeling it might be the reason for gtkmm not building in succession because of comment #7 - the missing macro. Anyways it would be nice to throw an error message here that anybody can understand pointing out the missing macro. »Syntax error« does not tell me there is something missing. Rearding comment #10 I doubt the macro is installed on my machine.
(In reply to comment #21) > I have not done a 'jhbuild bootstrap'. I use distro stuff if possible. OK. I have no expectation of jhbuild working without jhbuild bootstrap, based on long experience with it and based on the jhbuild documentation. Daniel disagrees, I know, but I'm not interested in that. > in comment #13 I wanted to point out the glibmm failed to build (Bug 590907 by > the way) So the gtkmm build would have failed eventually anyway due to a tool-old glibmm, even if it used the system one. So I don't think that's relevant to this bug report. We still need to know what's happening on Björn Lindqvist system. > Anyways it would be nice to throw an error message here that anybody can > understand pointing out the missing macro. > »Syntax error« does not tell me there is something missing. Well, yes, m4 is annoying.
(In reply to comment #22) > (In reply to comment #21) > > I have not done a 'jhbuild bootstrap'. I use distro stuff if possible. > > OK. I have no expectation of jhbuild working without jhbuild bootstrap, based > on long experience with it and based on the jhbuild documentation. Daniel > disagrees, I know, but I'm not interested in that. The macro is not being pulled in. I do not know yet what caused it, but I am looking for possible causes. You are hand-waving your experience. This is starting to get silly. > > in comment #13 I wanted to point out the glibmm failed to build (Bug 590907 by > > the way) > > So the gtkmm build would have failed eventually anyway due to a tool-old > glibmm, even if it used the system one. So I don't think that's relevant to > this bug report. We still need to know what's happening on Björn Lindqvist > system. Huh? He does not have a working glibmm installation and that's somehow not relevant to the bug report? > Well, yes, m4 is annoying. For your information, I already improved the new build infrastructure in that regard, by adding an m4_pattern_forbid() call to catch unexpanded MM_* macros in the output.
By the way, what's the output of locate glibmm_check_perl.m4 on your system?
nazgul@rivendell:/space/svn/gnome/gdm$ locate glibmm_check_perl.m4 nazgul@rivendell:/space/svn/gnome/gdm$ jhbuild run locate glibmm_check_perl.m4 nazgul@rivendell:/space/svn/gnome/gdm$
OK. Just to make sure that it wasn't just a stale locate database, could you have a look in the directories /usr/share/aclocal ${prefix}/share/aclocal where ${prefix} is the installation prefix as set in the .jhbuildrc file. Also, what's the output of aclocal --print-ac-dir on your system, both inside and outside the jhbuild environment? By the way, the problem cannot possibly occur anymore with gtkmm git master, since the build system has changed in major ways. The glibmm_check_perl.m4 file is still installed by glibmm for backwards-compatibility, however.
Closing as obsolete, since the build infrastructure has changed completely. The macro defined in glibmm_check_perl.m4 is still available but deprecated. It is not used anymore by gtkmm 2.18.