Bug 55924 - autoconf produces invalid output with some input
autoconf produces invalid output with some input
Product: Red Hat Raw Hide
Classification: Retired
Component: autoconf253 (Show other bugs)
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Jens Petersen
Brian Brock
Depends On:
  Show dependency treegraph
Reported: 2001-11-08 16:08 EST by Joshua J. Drake
Modified: 2007-04-18 12:38 EDT (History)
0 users

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

Attachments (Terms of Use)

  None (edit)
Description Joshua J. Drake 2001-11-08 16:08:59 EST
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 04:13:33 EST
"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 12:02:18 EST
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 00:39:49 EST
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 00:58:07 EST
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 08:31:08 EST
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.