gcc: bad value (x86_64) for -march= switch

[mschauer]

670a6a1 breaks my installation process on gcc (Debian 4.7.2-5)
gcc rejects -march=x86_64 and thinks it should be x86-64
as I understand https://bugzilla.redhat.com/show_bug.cgi?id=185507

 ~/y$ gcc test.c -march=x86-64
 ~/y$ gcc test.c -march=x86_64
test.c:1:0: error: bad value (x86_64) for -march= switch
 ~/y$ gcc --version
gcc (Debian 4.7.2-5) 4.7.2
Copyright (C) 2012 Free Software Foundation, Inc.

[mschauer]

cc @vtjnash

[vtjnash]

that should only happen if you are explicitly setting ARCH=x86_64, which should not be necessary, but if you do, you should also set MARCH=. if this is being set by the OS, then we should probably rename this internal parameter to not conflict

[mschauer]

Ah, apparently ARCH=x86_64 is set by the university's debian installation here, but MARCH not

[vtjnash]

MARCH is not a standard environment variable (ARCH isn't either, but is perhaps more common). However, in that commit, I started to use ARCH to detect a request to retarget the binary as a cross-compile for the requested architecture (this variable did that before too, but it ignored the user's environment variables)

[mschauer]

Just unsetting $ARCH or setting $MARCH did not work for me

[ArchRobison]

I ran into the same problem. My environment was setting $ARCH to the output of /usr/bin/arch. Unsetting $ARCH worked for me. Given the ubiquity of /usr/bin/arch, it may be worth normalizing the string in $ARCH to what gcc accepts.

I claim no expertise in this area despite being Arch.

[JeffBezanson]

Is x86-64 accepted everywhere? If so we can just normalize to that.

[vtjnash]

Normalizing to x86_64 is one option, the other is using a different variable or a different priority (eg clearing ARCH at the top of Make.inc, so it can't be picked up from the environment)

I don't know what is better, which is why I haven't done anything yet.