Re: Two-month patch ping: Re: powerpc*le-linux support

[Peter Rosin]

On 2013-08-22 17:48, Alan Modra wrote:
> On Thu, Aug 22, 2013 at 09:34:10PM +0700, Gary V. Vaughan wrote:
>>> How can it be correct to say "-m elf32lppclinux" (32-bit) when $host is
>>> explicitly 64-bit? That seems like utter garbage to me. What am I
>>> missing this time?
> 
> As far as I understand, this piece of libtool is supplying ld options
> when your host compiler defaults to something other than what $host
> implies.  Which sounds very strange, but consider that on a
> powerpc64-linux host your gcc will usually compile to both 32-bit and
> 64-bit objects.  Both 32-bit and 64-bit objects will run on the host,
> and whether gcc produces 32-bit by default (most common a few years
> ago) or 64-bit (most common now), depends on how gcc was configured.
> 
> So if $host is powerpc64-linux and $CC is gcc and gcc produces 64-bit
> by default, and $LD is powerpc64-linux-ld then no ld options are
> needed.  When generating 32-bit libraries on this system, $host is
> powerpc-linux, $CC is still gcc, and $LD may be powerpc-linux-ld.
> That's a problem because $CC with no options produces 64-bit objects
> but $LD with no options is expecting 32-bit.
> 
> This is all somewhat of a guess on my part, but I've seen these $LD
> and $CC selections.  Most configure scripts seem to prefer
> "powerpc64-linux-ld" over plain "ld" when $host is powerpc64-linux,
> and similarly "powerpc-linux-ld" for $host of powerpc-linux.

Sheesh. You are lying about $host, and get to keep all the pieces when
it breaks. If you have host=powerpc64le-*, but the compiler produces
powerpcle-* output, then why on earth didn't you say host=powerpcle-*
from the beginning? And when there is an obvious mismatch between $host
and the compiler output, that seems like a reason to abort to me, and
not a reason to use the obviously wrong value of $host to infer
something about what the compiler produces and spread the lie to ld.

I mean, if the compiler produces powerpcle output and $host matches
powerpc64-*, it is just dead wrong to feed -m elf32ppclinux to ld.
And similar for other three cases of crossing both the 32/64 boundary
and the endian boundary.

Taking one example I know of (I'm sure there are plenty), my Octave will
print this (among other things) when it starts up:

        Octave was configured for "i686-pc-cygwin".

I bet this is just a copy of $host. If you lie about $host when you
build software, that lie is going to spread like mad. So, there are
multiple reasons why this model is not sane. The only sane model is
to trust $host.

If you are building for 32le, say host=powerpcle-*
If you are building for 32be, say host=powerpc-*
If you are building for 64le, say host=powerpc64le-*
If you are building for 64be, say host=powerpc64-*

If you then want to avoid the cross-compile mode of autotools (which
is what all this boils down to, methinks), it is probably better to lie
about $build, it is not used nearly as much as $host. 

I realize that it is probably too late for the above. Sad. And I haven't
tried any of it either, so no doubt it's going to fail in some spectacular
way, but it seems much saner to me...

Given all the pain the "avoid cross-compile mode at all costs" mentality
is causing, it would be really nice if autotools could be taught (or told
how) to run run-time checks even in cross-compile mode, whenever that is
possible to do as in cases like this.

Crosses to MinGW from Cygwin or *ix with Wine come to mind as other
examples when people lie about $host/$build to evade the cross-compile
mode.

Cheers,
Peter