ports/67228: automake18: bad paths to autom4te

Brian Candler B.Candler at pobox.com
Wed May 26 17:51:27 UTC 2004


>Number:         67228
>Category:       ports
>Synopsis:       automake18: bad paths to autom4te
>Confidential:   no
>Severity:       serious
>Priority:       medium
>Responsible:    freebsd-ports-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Wed May 26 10:50:27 PDT 2004
>Closed-Date:
>Last-Modified:
>Originator:     Brian Candler
>Release:        FreeBSD 5.2.1-RELEASE i386
>Organization:
>Environment:

	
>Description:

>From package automake18, aclocal18 and automake18 try to run 'autom4te' when
they should actually run 'autom4te259'

More explicitly, in /usr/local/bin/aclocal18, 

  my $traces = ($ENV{AUTOM4TE} || 'autom4te');

should read

  my $traces = ($ENV{AUTOM4TE} || 'autom4te259');

Similarly, in /usr/local/bin/automake18,

  my $traces = ($ENV{AUTOCONF} || 'autoconf') . " ";

should read

  my $traces = ($ENV{AUTOCONF} || 'autoconf259') . " ";

I made those changes post-installation and now aclocal18/automake18 work fine.

	
>How-To-Repeat:
	

I cvsup'd my ports collection before building.

I did have an old version of autom4te lying around when I built package
automake18 (which in turn pulled in autoconf259)

$ pkg_info -W /usr/local/bin/autom4te
/usr/local/bin/autom4te was installed by package autoconf-2.53_1

Maybe the existence of that file confused things. But since automake18
explicitly pulls in autoconf259, then I think it should refer to autom4te259

Without the fix, the wrong (old) version of autom4te is run, which gives a
number of strange and confusing errors.

>Fix:

See above (although I've not investigated the best way to fix this within
the port; I just patched aclocal18/automake18 post-installation to make
them work)

>Release-Note:
>Audit-Trail:
>Unformatted:



More information about the freebsd-ports-bugs mailing list