cross-compilation tool detection

[Rainer Weikusat-3]

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@....

I indeed 'think' that naming programs according to any taxonomy I
might consider to be convenient, possibly including no taxonomy at
all (why shouldn't I call a cross-compiler 'Julia', should I so
desire?) is useful to me.

Kind of a weird question.


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Bob Friesenhahn]

On Tue, 13 Oct 2009, Rainer Weikusat wrote:
>
> I indeed 'think' that naming programs according to any taxonomy I
> might consider to be convenient, possibly including no taxonomy at
> all (why shouldn't I call a cross-compiler 'Julia', should I so
> desire?) is useful to me.

You are free to call your compiler anything you like but in the future
your code might not compile any more.

Since the build host also usually offers compilation tools, it is
quite useful if each set of tools is clearly demarked by a naming
convention so that the correct ones are used.  Use symbolic links to
establish one without modifying your tool installation.

Bob
--
Bob Friesenhahn
bfriesen@..., http://www.simplesystems.org/users/bfriesen/
GraphicsMagick Maintainer,    http://www.GraphicsMagick.org/


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

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@....

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, 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.

- --
Don't work too hard, make some time for fun as well!

Eric Blake             ebb9@...
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEARECAAYFAkrVIXQACgkQ84KuGfSFAYAcZwCfYylyfSh8prwGISeeFYSCbn4a
2aAAnjr7Ir4FoI4HsCGYNcqy8gd09xan
=vsvf
-----END PGP SIGNATURE-----


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Rainer Weikusat-3]

Eric Blake <ebb9@...> 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@....
>
> 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@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Harlan Stenn-5]

Rainer wrote:

> 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.

Have you seen any of my postings to this list about my 'cvo' script?

What you describe is exactly why I wrote it, and if one really has
multiple cpu-vendor-os-gcc programs that do different things, I'd put
them in different subdirectories so it was clear from their path what
their overall function was.

H


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Rainer Weikusat-3]

Harlan Stenn <stenn@...> writes:
> Rainer wrote:
>> 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.
>
> Have you seen any of my postings to this list about my 'cvo' script?

Since I have solely send the original e-mail because I do consider
this to be a useful feature and the message asked me to do so, how
could I?

> What you describe is exactly why I wrote it, and if one really has
> multiple cpu-vendor-os-gcc programs that do different things, I'd put
> them in different subdirectories so it was clear from their path what
> their overall function was.

I do not see how this argument could possibly ever lead to
anything. Every 'feature' of some software is

        a) considered to be crucial to the well-being of the universe
           as such by the person who invented it

        b) can be worked around somehow

b) is not an argument in favor of a).

Independently of this, I am in a timezone were it is now 21:30 and at
the end of a long work day spent with beating another auto*-based
buildsystem into submission. I do not usually ignore e-mails, that
would be impolite, but I am starting to have some troubles to
reply in a calm way for fatigue and frustration alone ...


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf

[Steffen Dettmer-2]

On Fri, Oct 16, 2009, Rainer Weikusat <rweikusat@...> wrote:
> > 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.

why not having arm-platform1-linux-gcc and arm-platform2-linux-gcc?
(maybe because evaluating vendor field is ugly/bad?).

What IMHO is even less useful is when autoconf may fall back from
arm-platform2-linux-gcc -E to /lib/cpp or alike.

> 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?

Yes, because it uses linux startup code. Actually I think "linux"
might not be perfectly suited, because linux with glibc (and its
startup code) may be very different to maybe a linux with another
libc or even without ELF support or so. But I don't know why a
triplet "prefix" is used instead of some arbitrary-name prefix
(like Julias_linux_glibc2-cc or so).

oki,

Steffen


_______________________________________________
Autoconf mailing list
Autoconf@...
http://lists.gnu.org/mailman/listinfo/autoconf