ON CURRENT, if CPUTYPE?=core-avx2 is set in /etc/make.conf, the build system will automatically translate it to "-march=haswell". While this is correct and understood by clang, it breaks lang/gcc in the configure step (since the latest update to lang/gcc) : configure:3587: /usr/ports/lang/gcc/work/build/./gcc/xgcc -B/usr/ports/lang/gcc/ work/build/./gcc/ -B/usr/local/x86_64-portbld-freebsd11.0/bin/ -B/usr/local/x86_ 64-portbld-freebsd11.0/lib/ -isystem /usr/local/x86_64-portbld-freebsd11.0/inclu de -isystem /usr/local/x86_64-portbld-freebsd11.0/sys-include -c -g -O2 -pipe -march=haswell -DLIBICONV_PLUG -fno-strict-aliasing conftest.c >&5 conftest.c:1:0: error: bad value (haswell) for -march= switch /* confdefs.h */ ^ configure:3591: $? = 1 configure: failed program was: | /* confdefs.h */ | #define PACKAGE_NAME "GNU C Runtime Library" | #define PACKAGE_TARNAME "libgcc" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU C Runtime Library 1.0" | #define PACKAGE_BUGREPORT "" | #define PACKAGE_URL "http://www.gnu.org/software/libgcc/" | /* end confdefs.h. */ | | int | main () | { | | ; | return 0; | } configure:3605: error: in `/usr/ports/lang/gcc/work/build/x86_64-portbld-freebsd 11.0/libgcc': configure:3608: error: cannot compute suffix of object files: cannot compile See `config.log' for more details. I can reproduce the issue with CPUTYPE?=core-avx-i, which gets translated to -march=ivybridge.
I don't think it's GCC's fault if "something" feeds it invalid input. Who has / feels ownership of this piece of make.conf?
The bug appears to be in the base system (/etc/make.conf).
The same behavior can also be observed for devel/valgrind and (I suspect) for a lot of ports relying on gcc in their configure stage and not stripping -march= completely.
It seems this is caused by changes introduced in r280159 to share/mk/bsd.cpu.mk In this revision some CPUTYPES are changed (in particular, the haswell and ivybridge ones I have problems with). Now the pending update of lang/gcc to gcc4.9 will likely solve this issue as the aliases are then the same as for recent clangs again. Still, it is somewhat unsatisfying.
Created attachment 162410 [details] Patch adding GitHub/PyPI site handlers
Comment on attachment 162410 [details] Patch adding GitHub/PyPI site handlers Ugh, ignore that.
Not a problem any longer as with the later llvm/clang imports to HEAD more modern CPUTYPEs are supported.