Bug 55924 - autoconf produces invalid output with some input
Summary: autoconf produces invalid output with some input
Alias: None
Product: Red Hat Raw Hide
Classification: Retired
Component: autoconf253   
(Show other bugs)
Version: 1.0
Hardware: i386 Linux
Target Milestone: ---
Assignee: Jens Petersen
QA Contact: Brian Brock
Depends On:
TreeView+ depends on / blocked
Reported: 2001-11-08 21:08 UTC by Joshua J. Drake
Modified: 2007-04-18 16:38 UTC (History)
0 users

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-03-27 05:58:12 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

Description Joshua J. Drake 2001-11-08 21:08:59 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i586; en-US; rv:0.9.5) Gecko/20011014

Description of problem:
autoconf generates invalid output (configure) from some valid input
(configure.in).  This started happening when autoconf was upgraded to

additionally, autoconf seems *much* slower and the following directory is
left behind after autoconf completes... autom4te.cache
Is this a release version of autoconf or what? hehehe

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1.get ftp://qoop.org/ninja/sources/ninja-1.5.5.tar.gz
2.uncompress (gzip -cd ninja*gz | tar xf -)
3.cd ninja-*5.5


Actual Results:  when running autoconf:
fear:ninja-1.5.6> autoconf
configure.in:1: error: possibly undefined macro: dnl

when running produced configure:
checking for sigaction... yes
./configure: line 6253: syntax error near unexpected token `else'
./configure: line 6253: `else'

Expected Results:  1. autoconf completion without error
2. configure complete successfully

Additional info:

Also, shouldn't autoconf check for presence and THEN usability of include
files?  Doesn't usability require presence?!

from ./configure output
checking sys/select.h usability... yes
checking sys/select.h presence... yes

Comment 1 Jens Petersen 2001-11-12 09:13:33 UTC
"autoconf --version" kind of gives the game away!

Yes, I can reproduce this with both autoconf-{2.50,2.52{,d,g}}.

However it is not clear with current information whether the problem with your
configure.in is an autoconf bug or not.

autoconf-2.52 differs considerably from autoconf-2.13 (the previous release),
and unfortunately some of the changes made break backwards compatibility, which
is quite likely what you're experiencing.

If you can pinpoint down the part of your configure.in that is causing the above
error, then I will be able to help further.

I asked on the autoconf list about the order the header usability and presence

Comment 2 Joshua J. Drake 2001-11-13 17:02:18 UTC
I'm not an autoconf expert, but I believe the problem is getting triggered
somewhere in the signal checking... about line 428..

Is there some place where I can find out what is not backwards compatabile??

It seems like all the new software thats coming out is taking a step backwards
instead of forwards...  ncftp even got rid of the "bgget -R" command!  man..

Comment 3 Jens Petersen 2002-03-27 05:39:49 UTC
ninja- seems to be ok with autoconf-2.52 and 2.53.
Did you find the problem or work around it?

Comment 4 Joshua J. Drake 2002-03-27 05:58:07 UTC
yeah i did manage to fix it, but now it doesn't work with the old one, heheheh

i'm not sure if its worth it to try to get it to work with both.. its stuff
inherited from ircII anyway

Comment 5 Jens Petersen 2002-03-27 13:31:08 UTC
you mean ninja now doesn't work with autoconf-2.13, right?  Well, if it works
with the current autoconf, I would be happy with that. :)

Note You need to log in before you can comment on or make changes to this bug.