Eric Blake <ebb9@xxxxxxx> writes: > According to Rainer Weikusat on 10/13/2009 9:49 AM: >> This mail being caused by having received the warning quoted below: >> >> configure: WARNING: In the future, Autoconf will not detect cross-tools >> whose name does not start with the host triplet. If you think this >> configuration is useful to you, please write to autoconf@xxxxxxxx > > If you regenerate your configure file with a newer autoconf, that > particular message has been reworded to not sound so scary or severe; we > have conceded that some people insist on running with non-triplet-prefixed > cross-tools, Calling a program arm-unknown-linux-gcc isn't particularly useful. Especially if there are two arm-unknown-linux-gcc's which are quite different, each of them needed for a particular cross-compilation environment on the same machine. And there is another issue, although not a technical one: Computers are good at remembering and dealing with 'details' without the need to use mnemonic tricks necessary for human minds to do their own 'systematization'. So why encode these technical details in the names of programs in such a way, as opposed to (referring to the environment mentioned above) assigning names which mean something to a user, eg based on the project the compiler is intended to be used for? Imagine (as isn't quite unlikely) all such projects involve Linux, why have it in each and every name? Just because some people compile code for other operating systems? > at which point the burden is on the user to get the calling > conventions right. We still recommend that you use > target-triplet-symlink names, if only to make your life with > cross-compilation less prone to unintended bugs. The day I wrote this e-mail, I was, along other things, busy with redermining why libpcap and tcpdump cannot be cross-compiled. The reason was that there is a test for really ancient Linux version in configure.in (versions < 2) which is supposed to print a message and abort if someone should, for whatever reason, try to build either of both on a 1.2.13 kernel despite these kernels do not support the functionality. When using a cross-compilation environment, this test (based on uname) cannot work and configure aborts because of that. The last time I had to do this was when integrating tcpdump 3.8.3 into the same OS. By that time, I was even still naive enough to try to fix this and send patches for my fix to the so-called responsible people who - in finest BSD-tradition - of course neither accept patches from outsiders nor ever fix problems which don't affect them And that's what makes 'life with cross-compilation difficult': The constant need to dig around ages-old auto*-code to determine why the next piece of software known to be working on the targer OS cannot be compiled because of what broken auto*-'magic'. _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf
