On 04/23/2012 06:17 AM, Peter Rosin wrote: >> So, in this case, configure has detected that it can run programs, >> and therefore AC_RUN_IFELSE invocations will run the test program. >> This is more reliable than relying on the 4th argument of AC_RUN_IFELSE, >> which is most often a (pessimistic or optimistic) guess. >> Therefore this outcome of $cross_compiling is DESIRABLE, not "wrong". > > Oh, but it is wrong, it is a cross compile. Claiming anything else > is just delusional. You can argue that the *effect* is desirable or > not all you like, but a cross it is.
It _IS_ a cross-compile, but in the special subset of cross-compiles that also happen to be executable from the host. And this opens up all sorts of problems where running the executable in a non-native environment gives outright confusing results (such as thinking that mingw supports symlinks). But that generally boils down to the bug of the person invoking configure lying about their environment, and not something intrinsically bad with our cross-compilation hueristics. And the set of platforms where a cross-compilation allows native execution is small enough that we already tend to recognize such bug reports (you're compiling for mingw but using cygwin? did you use the right arguments?), whether or not the user paid attention to the warning from configure. >> >> Sure it is possible to write non-portable code and non-portable unit tests. >> But this is irrelevant to a discussion about --build and --host. > > And I think it's relevant. Your proposed change leads to silent > differences depending on e.g. the presence of Wine. A cross-compilation environment where wine lets you run mingw binaries is slightly different from a cross-compilation environment where everything has to be guessed; both environments are interesting, to different sets of users. Maybe you are right that a knob to force build!=host mode even when the non-native binaries can be run, in order to use that knob to eliminate the surprises due to Wine, is worth adding; further patches will probably be welcome, but probably post-2.69 material (I'm already late enough on the release as it is). -- Eric Blake [email protected] +1-919-301-3266 Libvirt virtualization library http://libvirt.org
signature.asc
Description: OpenPGP digital signature
