On Fri, 28 Apr 2000, Peter Eisentraut wrote:
> Okay, so I don't claim to know a thing about cross-compilation, but the
> current confusion around these parts doesn't help either. So let's pose
> this question: How do you *define* a cross-compilation situation, at least
> for the purposes of the Autoconf environment? Among the suggestions were:
Approach #1 may not be perfect, but it is a lot better than approach
#2. Adding -cross or -nocross also seems like a hack if you ask me.
Perhaps this is a stupid idea, but what about some kind of
config.compare script that takes two arguments (the $host and the $build)
and figures out if the two are "really the same" or if a cross compile
is in order. There are always going to be all kinds of wacky combinations
where if test "$host" != "$build" is just not going to cut it. Why don't
we put these info a config.compare script that can be improved over time?
Mo Dejong
Red Hat Inc.
> 1) build != host -- That won't work because firstly config.sub isn't quite
> that smart to guarantee lexical equalness in all cases, the problem often
> being the vendor part being kinda random. Secondly it will unnecessarily
> restrict such cases as an i486 -> i586 build (or equivalent for sparc,
> alpha, etc.)
>
> 2) Test program fails to run. That will not always catch things such as a
> FreeBSD -> Linux build. But running a test program might fail because the
> run-time environment isn't set up right, for example problems with the
> dynamic linker. Or consider building in /tmp which might be mounted
> noexec. What you really need to test is if the program would run at the
> installation destination, but you can't really do that.
>
> So the --cross option being thrown around seems to indicate that you can't
> really define it either way. (However, adding an option to turn on a
> feature that isn't really defined strikes me as a little odd as well.) So
> what's the deal?
>
> --
> Peter Eisentraut Sernanders väg 10:115
> [EMAIL PROTECTED] 75262 Uppsala
> http://yi.org/peter-e/ Sweden
