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