Hi, On 18 April 2017 at 18:47, Jan Engelhardt wrote: > On Tuesday 2017-04-18 17:44, Mojca Miklavec wrote: >>On 18 April 2017 at 17:27, Jan Engelhardt wrote: >>> >>> That will invoke /usr/bin/powerpc-unknown-linux-gnu-gcc etc., which can >>> either >>> be the PPC compiler, or a shell script invoking an existing >>> native-by-default >>> gcc with more arguments. >> >>The problem of this approach is that the configure scripts etc. then >>assume that the computer where you run the configuration is not able >>to run the resulting binaries. > > Yes, that is a bit unfortunate -- but usually points to a problem > *elsewhere*. If a software package needs, say, an utility to generate > more source code from an IDL [think protobuf], the package in > question should ensure it uses the native compiler for these things. > I also acknowledge that autotools does not expose the native CC very > well.
No, the idea is not to use the native compiler. >From a random example using AC_TRY_RUN([...]) the configure script compiles the code for the host platform, runs it and checks whether the resulting binary crashes. The idea is to check the binary for *host* platform, not the guest. The autotools need to know whether the will actually run the code or not. When cross-compiling, the autotools cannot simply run the resulting binary and the result has to be guessed or a database of all features of all platforms needs to be present. When compiling natively, the code can easily run. If I use --host=powerpc-<whatever> on x86_64, how can autotools decide whether or not powerpc binaries can run or not? >>Building for i386 or ppc is not really cross-compiling in the >>traditional sense. An x86_64 machine can still run the ppc binaries >>without problems > > Last time I tried, x86_64 chips only support the i686 and AMD64 ISAs > natively. For something like ppc, one would need a binfmt_misc(5) > entry with some qemu magic attached. On Macs (10.4 - 10.5) it works automatically without any qemu magic (there is some rosetta-something in the background, but that's fully transparent for users). But in order not to get too off-topic: is anything about my proposed patch actually problematic? Mojca _______________________________________________ config-patches mailing list config-patches@gnu.org https://lists.gnu.org/mailman/listinfo/config-patches
