[geeks] ....excuse me, gcc?

[Phil Stracchino]

On 07/12/10 13:18, Phil Stracchino wrote:
> Trying to bootstrap a multilib (m32/m64) gcc-4.4.3 on Solaris 10 x86 ona
> dual-Xeon box (Nocona 64-bit microarchitecture)
> 
> checking for suffix of object files... configure: error: in
> `/netstore/src/gcc-4.4.3/obj-babylon4/i686-pc-solaris2.10/amd64/libgcc':
> configure: error: cannot compute suffix of object files: cannot compile
> 
> investigate further:
> 
> /netstore/src/gcc-4.4.3/obj-babylon4/./gcc/xgcc
> -B/netstore/src/gcc-4.4.3/obj-babylon4/./gcc/
> -B/usr/local/i686-pc-solaris2.10/bin/
> -B/usr/local/i686-pc-solaris2.10/lib/ -isystem
> /usr/local/i686-pc-solaris2.10/include -isystem
> /usr/local/i686-pc-solaris2.10/sys-include
> -L/netstore/src/gcc-4.4.3/obj-babylon4/./ld  -m64 -c -g -march=pentium4
> -mtune=nocona -mfpmath=sse -pipe   conftest.c
> conftest.c:1: error: CPU you selected does not support x86-64
> instruction set
> 
> 
> Excuse me?!?  On what planet does the Nocona core not support x86_64?
> 
> Anyone run into this before and know a way to smack gcc upside the head?


Never mind, solved it.

In theory, -march is the overall architecture family, and -mtune is
specific microarchitecture.  Or so I have always understood it.  But,
pentium4 includes both 32-bit-only and 32/64-bit architectures, and *in
this case*, gcc therefore assumes that -march=pentium4 implies 32-bit,
and *does not override this assumption* when -mtune=nocona is specified.
 So in this specific case, it's necessary to break the convention and
use -march=nocona directly (which I wasn't previously aware would even
work).


-- 
  Phil Stracchino, CDK#2     DoD#299792458     ICBM: 43.5607, -71.355
  alaric at caerllewys.net   alaric at metrocast.net   phil at co.ordinate.org
         Renaissance Man, Unix ronin, Perl hacker, Free Stater
                 It's not the years, it's the mileage.