Re: Patch for config.guess for "cross-compiling" x86_64 -> powerpc on Mac OS X <= 10.6

[Jan Engelhardt]

On Tuesday 2017-04-18 17:44, Mojca Miklavec wrote:
>On 18 April 2017 at 17:27, Jan Engelhardt wrote:
>>
>> On Tuesday 2017-04-18 17:18, Mojca Miklavec wrote:
>>>I would like to request a patch for config.guess to partially address
>>>some problems experienced when setting
>>>    CC="gcc -arch ppc"
>>>on Mac OS X 10.4-10.6 i386 or x86_64.
>>
>> At least on my side of the ocean, when cross-compiling, specifying the
>> triplet is the correct way.
>>  ./configure --host=powerpc-unknown-linux-gnu
>
>Do you also run
>    ./configure --host=i686-unknown-linux-gnu
>when you want to compile 32-bit binaries on 64-bit linux?

Well yes, and I have a number of different possible answers as to
why:


1. Because i686 is different ISA from AMD64.

2. If you were to only use CFLAGS=-m32, you would get a 32-bit binary
in the current ISA(*). This holds true for SPARC, powerpc and more
targets. (Possibly even ARMv8-A/aarch64, have not checked that yet.)

(*) The only exception is the x86_64 gcc where, due to historical
reasons, the 32-bit AMD64 mode is selected with -mx32 instead.

3. Distributions also pass --host all the time -- it tends to
affects paths (think usr/lib/perl5/5.8.12/i386-linux-thread-multi and
/usr/lib/i386-linux-gnu on some Linux distros).

If you were to omit --host=i686 and specify just CFLAGS=-m32, autoconf would
default to your current platform (assuming x86_64-linux) and you will

a. possibly end up installing an unwanted binary format into a x86_64 directory
when installing

b. have a "-m32"/"-mx32" binary load configuration files from a
x86_64 path meant for an x86_64 environment.


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

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

>(And if that was true ... why is then config.guess calling the
>compiler to differentiate between 32-bit and 64-bit darwin instead of
>simply asking the OS whether it's 64-bit capable?)

I never groked that part either. Maybe because some OSes did
not hand out that information through the normal channels?