Dave Korn wrote: > Cygwin uses 'alternatives' to manage automake: > > /artimi/software/firmware $ /usr/sbin/update-alternatives --config automake > > There are 8 programs which provide 'automake'. > > Selection Command > ----------------------------------------------- > 1 /usr/bin/automake-1.4 > 2 /usr/bin/automake-1.5 > 3 /usr/bin/automake-1.6 > 4 /usr/bin/automake-1.7 > 5 /usr/bin/automake-1.8 > 6 /usr/bin/automake-1.9 > 7 /usr/bin/automake-1.10 > *+ 8 /usr/share/autotools/am-wrapper.sh > > Enter to keep the current selection[+], or type selection number: > > The am-wrapper script is the one that tries to deduce and reuse the original > version used to first build the file, IIUIC.
I'm pretty sure that's not what's going on here; you'd see the same thing without alternatives or am-wrapper.sh because automake encodes the version number used to build the generated Makefile.in and then directly invokes that version as automake-n.n, bypassing all of the above. However, when you re-run autoreconf --force --verbose --install it is supposed to regenerate everything using the latest version, which means this embedded automake-1.9 reference should . I'm not sure why in Ross' case it's still trying to call automake-1.9 whereas in David's case it's not, but Ross also mentioned that he'd edited the cygport file to remove the autoreconf line which is definitely wrong -- running autoreconf is what should remove this dependency on the older version. Ross: try just unpacking the source tarball into a directory and running "autoreconf --force --verbose --install" there. If that doesn't work then we need to investigate why, outside of the context of cygport. Brian
