configure:6275: error: possibly undefined macro: AS_MESSAGE_LOG_FDdnl If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. from configure: Alternatively, you may set the environment variables GLIB_CFLAGS and GLIB_LIBS to avoid the need to call pkg-config. See the pkg-config man page for more details." "$LINENO" AS_MESSAGE_LOG_FDdnl from pkg.m4: m4_default([$4], [AC_MSG_ERROR( [Package requirements ($2) were not met: $$1_PKG_ERRORS Consider adjusting the PKG_CONFIG_PATH environment variable if you installed software in a non-standard prefix. _PKG_TEXT])dnl it needs a whitespace before the dnl...
i'm not sure if we should fix this is pkg-config, or if this is another regression of autoconf itself...
(In reply to comment #1) > i'm not sure if we should fix this is pkg-config, or if this is another > regression of autoconf itself... > s/is/in/ :)
http://bugzilla.redhat.com/show_bug.cgi?id=611781 http://cvs.fedoraproject.org/viewvc/rpms/pkgconfig/devel/pkg-config-dnl.patch?view=log http://lists.gnu.org/archive/html/autoconf/2010-07/msg00031.html
+*pkgconfig-0.25-r2 (11 Jul 2010) + + 11 Jul 2010; Samuli Suominen <ssuominen@gentoo.org> + +pkgconfig-0.25-r2.ebuild, +files/pkgconfig-0.25-dnl.patch: + Fix for sys-devel/autoconf-2.66 compat (but commit unkeyworded until it's + sorted out).
Hrm, the fedora patch looks reversed, and on the other hand I'm not sure if _dropping_ dnl is going to be the right thing to do. To me it looks a lot more like it's an autoconf bug...
that's why it's not keyworded :) waiting for upstream consensus.
alternative patch, http://repos.archlinux.org/wsvn/packages/pkg-config/trunk/autoconf-2.66.patch
And the upstream pkg-config bug/patch that likely introduced this regression: http://bugs.freedesktop.org/show_bug.cgi?id=13892
Archlinux wins. That patch is proper, and we could very well be applying it just to be on the safe side. The problem is that all the packages bundling pkg.m4 will have the same problem.
(In reply to comment #9) > Archlinux wins. That patch is proper, and we could very well be applying it > just to be on the safe side. applied in tree > The problem is that all the packages bundling pkg.m4 will have the same > problem. > will keep my eyes open...
You do know that we're talking of about 60% of the pkg-config users in the tree, right?
(In reply to comment #11) > You do know that we're talking of about 60% of the pkg-config users in the > tree, right? > I've seen it couple of times, but no idea on numbers... Perhaps tinderbox could run a custom pkg_ function and execute `find` pkg.m4 for ${WORKDIR} or ${S} in it?
Sure I could... but at that point I'd rather ask for Zac to write me some code to simply run the unpack/prepare phase of all the packages and check for the pkg.m4 file with the mistake in it ;P
http://bugs.freedesktop.org/show_bug.cgi?id=13892 was applied *after* 0.23 release, so the regression should be only in bundled 0.24 or 0.25 pkg.m4 files.
Hm okay then it is feasible, I guess, sorry for the extra noise
