From rfg@monkeys.com  Fri Nov 22 12:11:59 2002
Return-Path: <rfg@monkeys.com>
Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125])
	by hub.freebsd.org (Postfix) with ESMTP id 0AD9637B401
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 22 Nov 2002 12:11:59 -0800 (PST)
Received: from segfault.monkeys.com (segfault.monkeys.com [66.60.157.246])
	by mx1.FreeBSD.org (Postfix) with ESMTP id A3AAC43EA3
	for <FreeBSD-gnats-submit@freebsd.org>; Fri, 22 Nov 2002 12:11:58 -0800 (PST)
	(envelope-from rfg@monkeys.com)
Received: by segfault.monkeys.com (Postfix, from userid 1237)
	id 4DFD742251; Fri, 22 Nov 2002 12:11:58 -0800 (PST)
Message-Id: <20021122201158.4DFD742251@segfault.monkeys.com>
Date: Fri, 22 Nov 2002 12:11:58 -0800 (PST)
From: Ronald F.Guilmette <rfg@monkeys.com>
Reply-To: Ronald F.Guilmette <rfg@monkeys.com>
To: FreeBSD-gnats-submit@freebsd.org
Cc:
Subject: /usr/ports/devel/autoconf213 fails to build (affecting nmh)
X-Send-Pr-Version: 3.113
X-GNATS-Notify:

>Number:         45598
>Category:       ports
>Synopsis:       /usr/ports/devel/autoconf213 fails to build (affecting nmh)
>Confidential:   no
>Severity:       non-critical
>Priority:       medium
>Responsible:    alane
>State:          closed
>Quarter:        
>Keywords:       
>Date-Required:  
>Class:          change-request
>Submitter-Id:   current-users
>Arrival-Date:   Fri Nov 22 12:20:01 PST 2002
>Closed-Date:    Mon Dec 09 11:06:17 PST 2002
>Last-Modified:  Mon Dec 09 11:06:17 PST 2002
>Originator:     Ronald F. Guilmette
>Release:        FreeBSD 4.7-RELEASE i386
>Organization:
Infinite Monkeys & Co.
>Environment:
System: FreeBSD segfault.monkeys.com 4.7-RELEASE FreeBSD 4.7-RELEASE #0: Fri Nov 22 02:19:43 PST 2002 root@:/usr/src/sys/compile/rfg20021102 i386


>Description:
	Attempting to `make' in /usr/ports/mail/nmh causes an attempt to be
	made to build the /usr/ports/devel/autoconf213 port.

	Unfortunately, doing `make' in /usr/ports/devel/autoconf213 fails,
	for the reasons previously explained in PR ports/29392.

	(NOTE:  A copy of the log file from the make of nhm has been mailed
	to the port maintainer for autoconf.)

>How-To-Repeat:
	cd /usr/ports/mail/nmh
	make
>Fix:
	Please see PR ports/29392.

	In the Makefile for autoconf213, you simply have to re-arrange the
	command line arguments for each of the three invocations of
	$(MAKEINFO) so that the input filename is the last and final
	command line argument in each case.

	Doing that at least gets you past the build problems, however you
	are still left with a semi-brain-dead `makeinfo' command that will
	segfault on you (if you don't give it command line arguments in
	the exact order it seems to want).

	A *real* fix would be to find out why the makeinfo command is
	crashing/segfaulting when the name of its input file is not the
	last and final command line argument, and then hack it so that
	it won't segfault anymore.  (Sorry, this more proper and complete
	solution is left as an exercise for the reader.)
>Release-Note:
>Audit-Trail:

From: AlanE <alane@geeksrus.net>
To: "Ronald F.Guilmette" <rfg@monkeys.com>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: ports/45598: /usr/ports/devel/autoconf213 fails to build (affecting nmh)
Date: Fri, 22 Nov 2002 17:38:05 -0500

 On Fri, Nov 22, 2002 at 12:11:58PM -0800, Ronald F.Guilmette wrote:
 >
 >>Number:         45598
 >>Category:       ports
 >>Synopsis:       /usr/ports/devel/autoconf213 fails to build (affecting nmh)
 
 Problem is not reproducible. Autoconf213 builds correctly. I'm not going
 to patch the GNU make mess if the problem only affects one person.
 
 Ron, the problem lies in your machine, not in the port or in makeinfo.
 This port will be put in feedback state for 1 week, during which time
 submittor can provide evidence of failure on a different system. If no
 such evidence is forthcoming, the PR will be closed, as was its
 predecessor.
 
 I'm sorry, Ron, but that decision is final. Why don't you just build the
 autoconf213 port by itself using portupgrade and then portinstall nmh?
 I have too many things to worry about than to add patches to a port that
 only fails on one guy's system.
 
 -- 
 AlanE (Alan Eldridge), who likes fixing weird distributed systems bugs.
 Unix/C(++) IT Pro for 20 yrs, desperately seeking employment in NYC.
 (http://wwweasel.geeksrus.net/~alane/resume.rtf)
 KDE, KDE-FreeBSD Teams (http://www.kde.org, http://freebsd.kde.org/)
State-Changed-From-To: open->feedback 
State-Changed-By: alane 
State-Changed-When: Fri Nov 22 14:49:39 PST 2002 
State-Changed-Why:  
Need demonstration of reproducibility on another system. 


Class-Changed-From-To: sw-bug->change-request 
Class-Changed-By: alane 
Class-Changed-When: Fri Nov 22 14:49:39 PST 2002 
Class-Changed-Why:  
Problem only appears to affect this user's system. 


Responsible-Changed-From-To: freebsd-ports->alane 
Responsible-Changed-By: alane 
Responsible-Changed-When: Fri Nov 22 14:49:39 PST 2002 
Responsible-Changed-Why:  
I'm the damn maintainer of the auto**** portgs, that's bloody why. 

http://www.freebsd.org/cgi/query-pr.cgi?pr=45598 

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: alane@geeksrus.net
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: ports/45598: /usr/ports/devel/autoconf213 fails to build (affecting nmh) 
Date: Tue, 26 Nov 2002 15:47:09 -0800

 In message <20021122223805.GA77179@wwweasel.geeksrus.net>, you wrote:
 
 >On Fri, Nov 22, 2002 at 12:11:58PM -0800, Ronald F.Guilmette wrote:
 >>
 >>>Number:         45598
 >>>Category:       ports
 >>>Synopsis:       /usr/ports/devel/autoconf213 fails to build (affecting nmh)
 >
 >Problem is not reproducible. Autoconf213 builds correctly. I'm not going
 >to patch the GNU make mess if the problem only affects one person.
 >
 >Ron, the problem lies in your machine, not in the port or in makeinfo.
 >This port will be put in feedback state for 1 week, during which time
 >submittor can provide evidence of failure on a different system. If no
 >such evidence is forthcoming, the PR will be closed, as was its
 >predecessor.
 >
 >I'm sorry, Ron, but that decision is final. Why don't you just build the
 >autoconf213 port by itself using portupgrade and then portinstall nmh?
 >I have too many things to worry about than to add patches to a port that
 >only fails on one guy's system.
 
 
 OK, allow me to make a few comments...
 
 First, I don't really mind at all if you want to close out this bugreport,
 because in retrospect, it was rather badly done (on my part) anyway.  It
 doesn't state what the _real_ problem(s) is/are.
 
 I have investigated a bit more deeply now, and now I can say definitively
 that the _real_ problems are as follows:
 
 #1)  /usr/bin/makeinfo segfaults.  (It shouldn't do that, even when given
      command line arguments in a screwy order.)
 
      (Note that this problem is probably out of your jurisdiction, so
      don't worry about it.)
 
 #2)  The Makefile used within /usr/ports/devel/autoconf213 attempts to
      supply various option arguments to `makeinfo' _after_ the filename
      command line arguments.
 
      That's just not right, and it won't fly, even after the fundamental
      (segfault-causing) bug in `makeinfo' is fixed.
 
      (Basically, `makeinfo', like all UNIX commands that conform to POSIX
      IEEE Std. 1003.2-1992, Section 2.10.2, Guideline #9, expects and
      requires all of the option command line arguments to appear on the
      invocation line _before_ all of the other, non-option command line
      arguments.  But the Makefile for autoconf213 attempts, incorrectly
      and unworkably, to put the options _after_ the filename arguments
      when invoking `makeinfo'.  That clearly is a mistake, and it clearly
      cannot possibly work, because these days at least, `makeinfo' uses
      GNU getopt_long to parse all command line options and arguments,
      and that library routine, in turn, itself imposes the disipline that
      the options must preceed all of the non-option command line arguments.)
 
 I have already filed a separate bug report (with fix included) for problem
 #1 above (i.e. gnu/45744) and I have sent my fix also to the GNU Project
 people.  I will file and new and different bug report for problem #2,
 listed above, soon.  Probably today.
 
 I cannot account for the fact that you were unable to reproduce the bug(s)
 which are clearly present, both in the GNU `makeinfo' source code (causing
 the segfault, and documented in some detail in my gnu/45744 bugreport) and
 also in the Makefile(s) associated with /usr/ports/devel/autoconf213.  My
 only theory is that you may perhaps being using some sort of non-ordinary
 hardware.
 
 Did you ask any other people... preferably people with ordinary x86 hardware...
 to verify your negative results?  If so, what sorts of processors do those
 folks use?  (I have only AMD-K6 processors here, but those are failr `normal'
 as far as i know.)
 
 It does seem to me that if you had asked a couple of other people with
 ordinary x86 machines to try reproducing what I reported, then _somebody_
 should be able to do so without too much effort.
 
 (If you are reluctant to ask for help, I could ask around and see if I
 can find some volunteers.)
 
 Certainly, you can clearly see from my patch included in my gnu/45744
 bugreport (on `makinfo') that there *is* quite clearly a case there
 where a NULL pointer may be dereferenced, resulting is the segfault
 and coredump that I have reported, more than a year ago, and also again,
 recently.
 
 I don't believe that there is any basis for controversy about this.  The
 code speaks for itself, and the existing code is clearly wrong, and clearly
 subject to dereferencing of NULL pointers.
 
 Similarly, the code within the `main' function of `makeinfo' speaks for
 itself.  It clearly uses the GNU getopt_long library function to parse
 all command line arguments, and that function is documented to have
 behaviour which expects all options arguments to preceed all non-option
 arguments (consistant with POSIX guidelines).  Thus, it cannot be at all
 controversial that the invocations of `makeinfo' contained within the
 Makefiles of /usr/src/devel/autoconf213 in which option arguments are
 given *following* non-option arguments are clearly wrong, and that they
 clearly should be fixed.
 
 To summarize, these two bugs _are_ quite clearly and incontrovertably real,
 i.e. (1) the segfault bug in `makeinfo' and (2) the option ordering bug
 in the Makefiles for /usr/ports/devel/autoconf213.  There can be no doubt
 that both bugs are real and that both should be fixed, regardless of any
 one person's ability of inability to reproduce the exact negative symptoms
 of each of these bugs on some specific (single) platform.  As I say, the
 code speaks for itself, and the code is quite clearly busted.
 
 With regards to your comment that you aren't going to fix these bugs as
 long as only one person is reporting them as bugs, I can only say that
 I find that attitude odd.
 
 I do freely admit that I may perhaps be the last person on the planet
 who is still using `nmh' as my mail client, but I do like it, and I do
 continue to use it.  And it _is_ still present in the FreeBSD ports tree.
 If it is not going to be maintained, at least to the point where it can
 be built from sources, then perhaps it should be removed from the ports
 tree so that people will know that it's just not supported on FreeBSD
 anymore.
 
 I will also stipulate that perhaps the `nmh' port is the one and only
 piece of FreeBSD that still requires or has any use for the (otherwise
 obsolete) autoconf-2.13 package/port.  I'm frankly as surprised as any-
 one to see that there are _two_ versions of autoconf being distributed
 with FreeBSD (and maintained with it, for certain values of ``maintained''),
 one apparently obsolete and the other one apparently not.  I think that
 maybe we should both ask the current `nmh' port maintainer why the `nmh'
 port continues to be reliant on this now-obsolete version of GNU autoconf,
 when clearly there is a much fresher version available, and ported, right
 there in the ports tree, right next to /devel/autoconf213.  I confess
 that it is an enigma to me, and I'd love to know what some things in
 the ports tree are dependent on obsolete versions of other tools, just
 to get themselves built.
 
 Not that any of that is terribly important, mind you.
 
 The bottom line is that I have now submitted workable fixes for both of
 the two bugs I have noted above.  (You already have my trivial set of
 suggested patches for the Makefile in /usr/ports/devel/autoconf213 from
 my original bugreport over a year ago.)  If you elect not to fix the
 clearly evident bug in the Makefile for autoconf213, then that's OK
 with me.  I would only ask that in that case, please also notify whoever
 is the master person in charge of the entire ports tree to remove these
 packages entirely:
 
 	mail/nhm
 	devel/autoconf213
 
 Those should be removed entirely from the ports tree so that other people
 will not make the same mistake as I did, i.e. wrongly assuming that these
 packages are still being maintained, even though they have very few users.
 
 Thanks.

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: AlanE <alane@geeksrus.net>
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: ports/45598: /usr/ports/devel/autoconf213 fails to build (affecting nmh)
Date: Tue, 26 Nov 2002 15:54:45 -0800

 It would appear that the GNU Project's maintainer of the GNU texinfo
 package (which includes the `makeinfo' utility) concurs with my
 opinion that `makeinfo' contained a bug that could cause segfaults.
 
 It would also appear that he concurs with the patch for `makeinfo'
 that I sent him.
 
 ------- Forwarded Message
 
 Return-Path: karl@freefriends.org
 Delivery-Date: Tue Nov 26 15:16:30 2002
 Return-Path: <karl@freefriends.org>
 Delivered-To: rfg@monkeys.com
 Received: from f7.net (consort.superb.net [209.61.216.22])
 	by segfault.monkeys.com (Postfix) with ESMTP id AB1B24225E
 	for <rfg@monkeys.com>; Tue, 26 Nov 2002 15:16:28 -0800 (PST)
 Received: (from karl@localhost)
 	by f7.net (8.11.6/8.11.6) id gAQNGRb05480;
 	Tue, 26 Nov 2002 18:16:27 -0500
 Date: Tue, 26 Nov 2002 18:16:27 -0500
 Message-Id: <200211262316.gAQNGRb05480@f7.net>
 From: karl@freefriends.org (Karl Berry)
 To: rfg@monkeys.com
 Cc: bug-texinfo@gnu.org
 Subject: Re: Segfault in makeinfo in GNU texinfo-4.3 package (fix included)
 
     I have been experiencing segmentation faults in makeinfo for quite a
     long time now... over a year.  Please see:
 
         http://www.freebsd.org/cgi/query-pr.cgi?pr=45598
 
 Ah.  Sorry, I wasn't aware of this.
 
     Obviously, it *is* possible for name_index_alist[i] to have a NULL value,
 
 Indeed.  I moved the undefindex call after the conditional just as you
 suggested.
 
 Thanks much for the report and fix!
 
 ~karl
 
 ------- End of Forwarded Message
 

From: Alan Eldridge <alane@geeksrus.net>
To: rfg@monkeys.com
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: ports/45598: /usr/ports/devel/autoconf213 fails to build (affecting nmh) 
Date: Tue, 26 Nov 2002 19:40:09 +0008 (EST)

 ---Reply to mail from Ronald F. Guilmette about ports/45598: /usr/ports/devel/autoconf213 fails to build (affecting nmh) 
 > 
 > In message <20021122223805.GA77179@wwweasel.geeksrus.net>, you wrote:
 > 
 >>On Fri, Nov 22, 2002 at 12:11:58PM -0800, Ronald F.Guilmette wrote:
 >>>
 >>>>Number:         45598
 >>>>Category:       ports
 >>>>Synopsis:       /usr/ports/devel/autoconf213 fails to build (affecting nmh)
 >>
 >>Problem is not reproducible. Autoconf213 builds correctly. I'm not going
 >>to patch the GNU make mess if the problem only affects one person.
 >>
 >>Ron, the problem lies in your machine, not in the port or in makeinfo.
 >>This port will be put in feedback state for 1 week, during which time
 >>submittor can provide evidence of failure on a different system. If no
 >>such evidence is forthcoming, the PR will be closed, as was its
 >>predecessor.
 >>
 >>I'm sorry, Ron, but that decision is final. Why don't you just build the
 >>autoconf213 port by itself using portupgrade and then portinstall nmh?
 >>I have too many things to worry about than to add patches to a port that
 >>only fails on one guy's system.
 > 
 > 
 > OK, allow me to make a few comments...
 > 
 > First, I don't really mind at all if you want to close out this bugreport,
 > because in retrospect, it was rather badly done (on my part) anyway.  It
 > doesn't state what the _real_ problem(s) is/are.
 > 
 > I have investigated a bit more deeply now, and now I can say definitively
 > that the _real_ problems are as follows:
 > 
 > #1)  /usr/bin/makeinfo segfaults.  (It shouldn't do that, even when given
 >      command line arguments in a screwy order.)
 > 
 >      (Note that this problem is probably out of your jurisdiction, so
 >      don't worry about it.)
 > 
 > #2)  The Makefile used within /usr/ports/devel/autoconf213 attempts to
 >      supply various option arguments to `makeinfo' _after_ the filename
 >      command line arguments.
 > 
 >      That's just not right, and it won't fly, even after the fundamental
 >      (segfault-causing) bug in `makeinfo' is fixed.
 > 
 >      (Basically, `makeinfo', like all UNIX commands that conform to POSIX
 >      IEEE Std. 1003.2-1992, Section 2.10.2, Guideline #9, expects and
 >      requires all of the option command line arguments to appear on the
 >      invocation line _before_ all of the other, non-option command line
 >      arguments.  But the Makefile for autoconf213 attempts, incorrectly
 >      and unworkably, to put the options _after_ the filename arguments
 >      when invoking `makeinfo'.  That clearly is a mistake, and it clearly
 >      cannot possibly work, because these days at least, `makeinfo' uses
 >      GNU getopt_long to parse all command line options and arguments,
 >      and that library routine, in turn, itself imposes the disipline that
 >      the options must preceed all of the non-option command line arguments.)
 > 
 > I have already filed a separate bug report (with fix included) for problem
 > #1 above (i.e. gnu/45744) and I have sent my fix also to the GNU Project
 > people.  I will file and new and different bug report for problem #2,
 > listed above, soon.  Probably today.
 > 
 > I cannot account for the fact that you were unable to reproduce the bug(s)
 > which are clearly present, both in the GNU `makeinfo' source code (causing
 > the segfault, and documented in some detail in my gnu/45744 bugreport) and
 > also in the Makefile(s) associated with /usr/ports/devel/autoconf213.  My
 > only theory is that you may perhaps being using some sort of non-ordinary
 > hardware.
 > 
 > Did you ask any other people... preferably people with ordinary x86 hardware...
 > to verify your negative results?  If so, what sorts of processors do those
 > folks use?  (I have only AMD-K6 processors here, but those are failr `normal'
 > as far as i know.)
 > 
 > It does seem to me that if you had asked a couple of other people with
 > ordinary x86 machines to try reproducing what I reported, then _somebody_
 > should be able to do so without too much effort.
 > 
 > (If you are reluctant to ask for help, I could ask around and see if I
 > can find some volunteers.)
 > 
 > Certainly, you can clearly see from my patch included in my gnu/45744
 > bugreport (on `makinfo') that there *is* quite clearly a case there
 > where a NULL pointer may be dereferenced, resulting is the segfault
 > and coredump that I have reported, more than a year ago, and also again,
 > recently.
 > 
 > I don't believe that there is any basis for controversy about this.  The
 > code speaks for itself, and the existing code is clearly wrong, and clearly
 > subject to dereferencing of NULL pointers.
 > 
 > Similarly, the code within the `main' function of `makeinfo' speaks for
 > itself.  It clearly uses the GNU getopt_long library function to parse
 > all command line arguments, and that function is documented to have
 > behaviour which expects all options arguments to preceed all non-option
 > arguments (consistant with POSIX guidelines).  Thus, it cannot be at all
 > controversial that the invocations of `makeinfo' contained within the
 > Makefiles of /usr/src/devel/autoconf213 in which option arguments are
 > given *following* non-option arguments are clearly wrong, and that they
 > clearly should be fixed.
 > 
 > To summarize, these two bugs _are_ quite clearly and incontrovertably real,
 > i.e. (1) the segfault bug in `makeinfo' and (2) the option ordering bug
 > in the Makefiles for /usr/ports/devel/autoconf213.  There can be no doubt
 > that both bugs are real and that both should be fixed, regardless of any
 > one person's ability of inability to reproduce the exact negative symptoms
 > of each of these bugs on some specific (single) platform.  As I say, the
 > code speaks for itself, and the code is quite clearly busted.
 > 
 > With regards to your comment that you aren't going to fix these bugs as
 > long as only one person is reporting them as bugs, I can only say that
 > I find that attitude odd.
 > 
 > I do freely admit that I may perhaps be the last person on the planet
 > who is still using `nmh' as my mail client, but I do like it, and I do
 > continue to use it.  And it _is_ still present in the FreeBSD ports tree.
 > If it is not going to be maintained, at least to the point where it can
 > be built from sources, then perhaps it should be removed from the ports
 > tree so that people will know that it's just not supported on FreeBSD
 > anymore.
 > 
 > I will also stipulate that perhaps the `nmh' port is the one and only
 > piece of FreeBSD that still requires or has any use for the (otherwise
 > obsolete) autoconf-2.13 package/port.  I'm frankly as surprised as any-
 > one to see that there are _two_ versions of autoconf being distributed
 > with FreeBSD (and maintained with it, for certain values of ``maintained''),
 > one apparently obsolete and the other one apparently not.  I think that
 > maybe we should both ask the current `nmh' port maintainer why the `nmh'
 > port continues to be reliant on this now-obsolete version of GNU autoconf,
 > when clearly there is a much fresher version available, and ported, right
 > there in the ports tree, right next to /devel/autoconf213.  I confess
 > that it is an enigma to me, and I'd love to know what some things in
 > the ports tree are dependent on obsolete versions of other tools, just
 > to get themselves built.
 > 
 > Not that any of that is terribly important, mind you.
 > 
 > The bottom line is that I have now submitted workable fixes for both of
 > the two bugs I have noted above.  (You already have my trivial set of
 > suggested patches for the Makefile in /usr/ports/devel/autoconf213 from
 > my original bugreport over a year ago.)  If you elect not to fix the
 > clearly evident bug in the Makefile for autoconf213, then that's OK
 > with me.  I would only ask that in that case, please also notify whoever
 > is the master person in charge of the entire ports tree to remove these
 > packages entirely:
 > 
 >     mail/nhm
 >     devel/autoconf213
 > 
 > Those should be removed entirely from the ports tree so that other people
 > will not make the same mistake as I did, i.e. wrongly assuming that these
 > packages are still being maintained, even though they have very few users.
 > 
 > Thanks.
 > 
 
 Ron, I have a stock PIII/733 box running a version of STABLE that is 3
 days old.
 
 /usr/bin/makeinfo does not segfault, nor has it ever. If I can build w/o
 this problem and the bento cluster can build w/o this problem, I will
 not change my position regards patching autoconf213.
 
 ---End reply
 
 -- 
 AlanE (Alan Eldridge), who likes fixing weird distributed systems bugs.
 Unix/C(++) IT Pro for 20 yrs, desperately seeking employment in NYC.
 (http://wwweasel.geeksrus.net/~alane/resume.rtf)
 KDE, KDE-FreeBSD Teams (http://www.kde.org, http://freebsd.kde.org/)
 
 

From: "Ronald F. Guilmette" <rfg@monkeys.com>
To: alane@geeksrus.net
Cc: FreeBSD-gnats-submit@FreeBSD.ORG
Subject: Re: ports/45598: /usr/ports/devel/autoconf213 fails to build (affecting nmh) 
Date: Tue, 26 Nov 2002 17:20:35 -0800

 In message <200211270040.gAR0eAe8061034@wwweasel.geeksrus.net>, you wrote:
 
 >Ron, I have a stock PIII/733 box running a version of STABLE that is 3
 >days old.
 >
 >/usr/bin/makeinfo does not segfault, nor has it ever. If I can build w/o
 >this problem and the bento cluster can build w/o this problem, I will
 >not change my position regards patching autoconf213.
 
 
 Can you please send me a log of your build of autoconf213?
 
 I would just like to see if, when you build it, the `makeinfo'
 utility program gets invoked with command line option arguments
 _following_ the filename command line argument, and if so,
 whether or not that elicits any complaints or warnings from
 makeinfo.
 
 Thanks.
 
 
 P.S.  There _should_ be some errors, because the given the command line:
 
    makeinfo -I. ./autoconf.texi --no-split --output=autoconf213.info
 
 the way that makeinfo is programmed, it _must_ necessarily see all of
 the arguments after the ./autoconf.texi as also being *input filenames*.
 And thus, you should get two errors, like:
 
     --no-split: File not found
     --output=autoconf213.info: File not found
 
 If you are not getting such errors, then I'd love for you to enlighten
 me about how you are avoiding doing so.  The man page for getopt_long:
 
    http://netbsd.gw.com/cgi-bin/man-cgi?getopt_long+3
 
 makes clear that all command line arguments past the first non-option
 argument will *not* be treated as option arguments.
 
 There's no point in us disagreeing about this.  The spec for getopt_long
 is perfectly clear on this point (and it is consistant with POSIX specs),
 and if you look at the source code for `makeinfo' you'll see quite
 clearly that it uses GNU getopt_long to parse makeinfo's command line
 arguments.  (The `makeinfo' man page is also pretty clear that all
 options must come first, followed by all filename arguments.)
 
 P.P.S.  If you look at the the _current_ GNU version of autoconf, and/or
 any version since 2.54 (released Sept 13th of this year) you'll see that
 this (command line argument ordering) bug has already been fixed in the
 newer GNU versions of autoconf.  In those (GNU) releases, the options
 given on invocations of `makeinfo' already come first, before the filename
 arguments.
 
 I'm basically only suggesting that the FreeBSD port(s) of autoconf should
 follow suit.
 
 Doesn't seem very controversial to me.
State-Changed-From-To: feedback->closed 
State-Changed-By: alane 
State-Changed-When: Mon Dec 9 11:06:09 PST 2002 
State-Changed-Why: not a demonstrable problem IMO 

http://www.freebsd.org/cgi/query-pr.cgi?pr=45598 
>Unformatted:
