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 300232 - pkgconfig-0.16.0 m4 file breaks gtk+ autogen.sh (gnome-2.12 moduleset)
pkgconfig-0.16.0 m4 file breaks gtk+ autogen.sh (gnome-2.12 moduleset)
Status: RESOLVED FIXED
Product: gtk+
Classification: Platform
Component: .General
2.6.x
Other All
: Normal normal
: ---
Assigned To: gtk-bugs
gtk-bugs
Depends on:
Blocks:
 
 
Reported: 2005-04-11 17:53 UTC by Fabrice Bellet
Modified: 2005-04-12 14:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Fabrice Bellet 2005-04-11 17:53:23 UTC 
Please describe the problem:
the pkg.m4 file from pkgconfig-0.16.0 contains some definitions, that breaks
autogen.sh in gtk+, that fails with this error message :

configure.in:131: error: possibly undefined macro: dnl
      If this token and others are legitimate, please use m4_pattern_allow.
      See the Autoconf documentation.

it works fine with pkgconfig-0.15.0

Steps to reproduce:
1. 
2. 
3. 


Actual results:


Expected results:


Does this happen every time?


Other information:
Comment 1 James Henstridge 2005-04-12 02:45:54 UTC 
This looks like the PKG_CHECK_MODULES() macro in pkg-config-0.16.0 seems to be
double-escaping some strings, which results in the "dnl" not being evaluated
like it was in pkg-config < 0.16.0.

I think this is a pkg-config bug, which I'll file upstream.
Comment 2 James Henstridge 2005-04-12 03:03:03 UTC 
Reassigning to GTK+, since the problem is either a GTK+ or pkg-config bug (the
only part jhbuild plays here is that it's bootstrap pulls in the latest version
of pkg-config).

I've filed a related bug against pkg-config here:
    https://bugs.freedesktop.org/show_bug.cgi?id=2987
Comment 3 James Henstridge 2005-04-12 14:12:24 UTC 
Marking bug as fixed, since pkg-config-0.17 is out now which includes a fixed M4
macro.

The autoconf error is a bit misleading due to the way the "forbidden patterns"
code works, which is essentially like this:
 1. allowed and forbidden patterns are registered by macros
 2. output of m4 is grepped for words matching forbidden patterns that don't
    match an allowed pattern.
 3. If any such words are found in the output, then something has gone wrong.
    The configure.in file is checked for the forbidden pattern that matched,
    and the line number of the first occurence is included in the error
    message.

Now "dnl" is one of the forbidden words, and was getting through to the final
output, due to a change in the quoting behaviour in the 0.16.0 M4 macro (since
reverted in 0.17).  However "dnl" is a pretty common M4 macro, so it's not
surprising that there was an earlier occurence ...