[Bob Proulx] > I disagree. It is wrong for config.guess to use 'uname -p' unless > it knows it is an okay thing to do on that particular host since > that is a non-standard thing to do. It has no right to count on it > being there.
Feel free to discuss this with the maintainers of config.guess. > Perhaps on the configure command line you could force the selection. > Something like this example. But these are from an x86. Replace with > your appropriate values. > > ./configure --host=i386-linux --build=i386-linux Well, of course this works, but it is not an option when I use the same compile script to compile the program on 9 different architectures. I would rather fix the auto-detection. > Perhaps you could update your config.guess and config.sub on a > failing package to the newest available and see if that helps. Both > of those are needed and go together. I believe the canonical and > newest versions are here. (I hope I have that right.) On hosts > that are not as mainstream I frequently find I need to update those > files. The problem occurs with the latest config.guess. It only occurs if GNU uname is first in the PATH. If I make sure /usr/bin/uname is first in the path, the output from config.guess is correct. I do not understand why you insist there must be something else wrong. Is it so hard to make GNU uname return 'powerpc' instead of 'unknown' as the hardware type on Darwin? _______________________________________________ Bug-sh-utils mailing list [EMAIL PROTECTED] http://mail.gnu.org/mailman/listinfo/bug-sh-utils
