Bug 29392

Summary: Small built-time glitch in Makefile for autoconf port
Product: Ports & Packages Reporter: Ronald F. Guilmette <rfg>
Component: Individual Port(s)Assignee: Alan Eldridge <alane>
Status: Closed FIXED    
Severity: Affects Only Me    
Priority: Normal    
Version: Latest   
Hardware: Any   
OS: Any   

Description Ronald F. Guilmette 2001-08-02 19:10:00 UTC 
	While making the autoconf port on FreeBSD 4.3-RELEASE, the process
	died when invoking `makeinfo':

	...
	freezing autoconf.m4
	freezing autoheader.m4
	makeinfo -I. ./autoconf.texi --no-split --output=autoconf.info
	--no-split: No such file or directory
	Segmentation fault - core dumped
	*** Error code 139
	
	Stop in /usr/ports/devel/autoconf/work/autoconf-2.13.
	*** Error code 1
	
	Stop in /usr/ports/devel/autoconf.
	*** Error code 1
	
	Stop in /usr/ports/devel/autoconf.
	*** Error code 1
	
	Stop in /usr/ports/devel/autoconf.
	*** Error code 1
	
	Stop in /usr/ports/devel/autoconf.
	*** Error code 1

Fix: 

I tried just rearranging the order of the command line arguments
	being supplied to `makeinfo' and found that if one simply puts
	the name of the input file LAST on the command line, following all
	of the options, then makeinfo seem to work just fine.  (Note that
	there are three separate invocations of `makeinfo' within the
	autoconfo port Makefile, and I had to change all three.)

	Anyway, that's the quick and dirty solution to this problem that
	just gets you past the build problem for the autoconf port.  But
	obviously, `makeinfo' should not be segfaulting, even if you give
	it command line arguments & options in some unusual order.  So
	there is still some unresolved problem there, and I don't have a
	suggsted fix for that.  Somebody will need to run gdb on it.
How-To-Repeat: 	cd /usr/ports/devel/autoconf
	make
Comment 1 Mario Sergio Fujikawa Ferreira freebsd_committer freebsd_triage 2001-08-02 20:17:37 UTC 
Responsible Changed
From-To: freebsd-ports->torstenb

Over to maintainer.
Comment 2 FUJISHIMA Satsuki freebsd_committer freebsd_triage 2001-09-22 21:01:20 UTC 
Responsible Changed
From-To: torstenb->freebsd-ports

Unresponsive maintainer.
Comment 3 Pete Fritchman freebsd_committer freebsd_triage 2001-11-29 18:31:30 UTC 
Responsible Changed
From-To: freebsd-ports->portmgr

Over to maintainer
Comment 4 Tilman Keskinoz freebsd_committer freebsd_triage 2002-10-20 18:11:14 UTC 
Responsible Changed
From-To: portmgr->alane

AlanE is our new autoconf Maintainer
Comment 5 Alan Eldridge freebsd_committer freebsd_triage 2002-10-20 21:20:44 UTC 
State Changed
From-To: open->closed

Makeinfo is part of the base system. Obviously, the port doesn't work on 
that old a system. Solution is to upgrade base system (or at least makeinfo).
Comment 6 Ronald F. Guilmette 2002-11-21 07:44:16 UTC 
This bug should *not* have been closed!

I have just installed 4.7-RELEASE and the same damn bug is still there!

C'mon!  I reported this bug over a year ago, *and* I provided the fix!

It is *not valid* to say "autoconf is part of the base, and thereore we
can ignore the evident build problems in the PORTS version of autoconf".

The problem is that *some other* things in the ports tree (mozilla?) have
the version of autoconf that also resides in the ports tree listed as some
sort of a necessary precursor or something.  So one gets stuck trying to
build the (broken) version of autoconf in the ports tree whether one likes
it or not, e.g. when you are just trying to build mozilla.

That's exactly how/why I found this bug in the first place!

I mean do you think that I go around building stuff in the ports tree
just for laughs, even if they are are already installed as part of the
base system???  No!  I was _trying_ to build *something else* when this
bug bit me in the ass and I had to figure out why the autoconf Makefile
was glitched *and* how to fix it, which I did, and dutifully reported my
findings.

So here we are, more than a year later, and the &^%$#@ thing is still
busted, and I had to go back and find my own &^%&%$@# PR again, just to
refresh my own memory about what the proper fix was again... a trivial
and obvious fix that you maintainer dudes could have, and should have
applied over a year ago, when I first gave it to you.

Please reopen this bug and close it properly this time.  I already
provided the fix in my original bug report.

I don't see it as being a very good use of people's time to make every
FreeBSD user fix this bug again every time a new FreeBSD release comes
out.  (This was originally reported in 4.3-RELEASE and it is still busted
in 4.7-RELEASE!)