list of --host options

[Joao Miguel Ferreira]

Hello all,

where can I find a list of the currentlly supported --host=myHost
options for cross compilation... (linux, hp, sun, cygwin, etc)

thank you

Joao

[Benoit SIGOURE]

Post by Joao Miguel Ferreira
Hello all,

Hello Joao Miguel,

Post by Joao Miguel Ferreira
where can I find a list of the currentlly supported --host=myHost
options for cross compilation... (linux, hp, sun, cygwin, etc)

AFAIK there is no such list, however as soon as you use
AC_CANONICAL_HOST in configure.ac *and* you use automake, automake
will install config.sub and config.guess. The role of config.sub is
to validate and canonicalize a given --host whereas the role of
config.guess is to guess a canonical system name.

# Find the canonical name of mingw32
$ ./config.sub mingw32
i386-pc-mingw32

# Find the canonical name of my system
$ ./config.guess
i386-apple-darwin8.10.1

By looking at the switch-case done by these scripts, you can figure
out the various hosts recognized by --host.

By the way, I have a question to the list, AC_CANONICAL_HOST implies
AC_CANONICAL_BUILD, maybe this should be mentionned in the
documentation? Also, is it normal that I absolutely need to use
automake in order to use AC_CANONICAL_*? Actually, as soon as you
use AC_CANONICAL_*, configure will require install-sh, which is
installed by automake. Thus you have to use AM_INIT_AUTOMAKE and at
least add an empty Makefile.am and use AC_CONFIG_FILES([Makefile]).

[Eric Blake]

Post by Benoit SIGOURE
By the way, I have a question to the list, AC_CANONICAL_HOST implies
AC_CANONICAL_BUILD, maybe this should be mentionned in the
documentation?

Why not propose a patch?

Post by Benoit SIGOURE
Also, is it normal that I absolutely need to use
automake in order to use AC_CANONICAL_*?

No. Autoconf also ships with a version of install-sh, so if you really
want to avoid automake, then you can manually add the install-sh from
autoconf into your project rather than requiring automake to install it
for you. Automake merely makes the task easier.

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

Eric Blake ***@byu.net

[Benoit SIGOURE]

Post by Eric Blake

Post by Benoit SIGOURE
By the way, I have a question to the list, AC_CANONICAL_HOST implies
AC_CANONICAL_BUILD, maybe this should be mentionned in the
documentation?

Why not propose a patch?

Done before you asked :)

Post by Eric Blake

Post by Benoit SIGOURE
Also, is it normal that I absolutely need to use
automake in order to use AC_CANONICAL_*?

No. Autoconf also ships with a version of install-sh, so if you really
want to avoid automake, then you can manually add the install-sh from
autoconf into your project rather than requiring automake to
install it
for you. Automake merely makes the task easier.

Alright but the problem ATM is that configure complains that install-
sh is missing when one runs it. Wouldn't it be better to report that
install-sh is missing at autoconf time? This would make it possible
to tell "you can cp install-sh from /path/to/where/autoconf/install/
has/put/it". Or if this isn't possible, I think the error message
given by configure should make it clear that the user can (and
actually should) copy install-sh from autoconf. I had the feeling
that I had done something wrong, and manually copying install-sh
would have felt like a "dirty workaround" whereas it's the right
thing to do.

Cheers,

[Eric Blake]

Alright but the problem ATM is that configure complains that install-sh
is missing when one runs it. Wouldn't it be better to report that
install-sh is missing at autoconf time? This would make it possible to
tell "you can cp install-sh from
/path/to/where/autoconf/install/has/put/it".

Not only that, but there is also the issue that autoconf doesn't enforce
that install-sh should be executable, because it's usage is so entrenched
without prefixing with $SHELL that things break if it is not executable
(witness the recent texinfo release):
http://lists.gnu.org/archive/html/bug-autoconf/2007-09/msg00011.html
http://lists.gnu.org/archive/html/autoconf-patches/2007-09/msg00049.html

You are correct that the _right_ way for autoconf to do things is to
complain loudly if install-sh is not present and executable, rather than
waiting for ./configure to do the job. I only worry about whether this
will break some packages bootstrapping paradigm, if they run autoconf
prior to automake.

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

Eric Blake ***@byu.net

[Brian Dessent]

Post by Joao Miguel Ferreira
where can I find a list of the currentlly supported --host=myHost
options for cross compilation... (linux, hp, sun, cygwin, etc)

This is not really something that autoconf determines. Whether or not
cross compiling with a given --host works or not is really more a
function of whether you have a functional cross-toolchain of that name
installed or not. If it's there, autoconf will try to use it, otherwise
it will fail.

In terms of getting a list of host triplets, you can look at the
config.guess file, or look at the subject-lines of the gcc-testresults
mailing list archives for another perspective. But keep in mind that
host triplets are somewhat of a freeform field: there are many
non-canonical forms in use. For example, some people might use
"i386-linux", others "i686-pc-linux-gnu", others "i486-unknown-linux",
maybe "i686-suse-linux-gnu", etc. As long as you are consistent in how
you name your cross-toolchain and what you specify for --host, it
doesn't really matter. The part that matters is whether there is a
working foo-cc, foo-ld, foo-as, foo-ar, foo-ranlib, etc.

Brian