On Fri, Aug 23, 2013 at 10:39:42AM +0200, Peter Rosin wrote: > 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
You're jumping to a completely wrong conclusion. No "lying", avoiding cross-compilation or any such thing. Just a bi-arch compiler. The same $CC for native powerpc64-linux and a powerpc64-linux to powerpc-linux cross. Why don't *you* do some digging to see what this code is about? Obviously my explanation, which as I said is somewhat of a guess, missed the mark. -- Alan Modra Australia Development Lab, IBM
