Re: cross-compilation tool detection

[Rainer Weikusat]

Eric Blake <address@hidden> 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 address@hidden
>
> 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'.