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. > I don't get it either, and I can't test it. I trust the ppcle community > will commence shouting if the patches have done something horrible. It's broken. Please apply exactly the tested patch I submitted, or if powerpc-* and similar in the switch statement is somehow the wrong style (we've tested for powerpc*-*linux* already!), then make them powerpc-*linux*. Not powerpc*-*linux*, which is exactly the same mistake I made with my first patch.. -- Alan Modra Australia Development Lab, IBM
