gcc8+: doesn't work on macOS 10.6

[catap (Kirill A. Korinsky)]

A naive test:

#include <stdio.h>
int main() {
   printf("Hello, World!");
   return 0;
}

fails as:

snow-leopard:tmp catap$ gcc-mp-13 -o test test.c -v
Using built-in specs.
COLLECT_GCC=gcc-mp-13
COLLECT_LTO_WRAPPER=/opt/local/libexec/gcc/x86_64-apple-darwin10/13.2.0/lto-wrapper
Target: x86_64-apple-darwin10
Configured with: /opt/local/var/macports/build/_opt_bblocal_var_buildworker_ports_build_ports_lang_gcc13/gcc13/work/gcc-13.2.0/configure --prefix=/opt/local --build=x86_64-apple-darwin10 --enable-languages=c,c++,objc,obj-c++,lto,fortran,jit --libdir=/opt/local/lib/gcc13 --includedir=/opt/local/include/gcc13 --infodir=/opt/local/share/info --mandir=/opt/local/share/man --datarootdir=/opt/local/share/gcc-13 --with-local-prefix=/opt/local --with-system-zlib --disable-nls --program-suffix=-mp-13 --with-gxx-include-dir=/opt/local/include/gcc13/c++/ --with-gmp=/opt/local --with-mpfr=/opt/local --with-mpc=/opt/local --with-isl=/opt/local --with-zstd=/opt/local --enable-checking=release --disable-multilib --enable-lto --enable-libstdcxx-time --without-build-config --with-as=/opt/local/bin/as --with-ld=/opt/local/bin/ld --with-ar=/opt/local/bin/ar --with-bugurl=https://trac.macports.org/newticket --enable-host-shared --with-darwin-extra-rpath=/opt/local/lib/libgcc --with-libiconv-prefix=/opt/local --disable-tls --with-gxx-libcxx-include-dir=/opt/local/libexec/gcc13/libc++/include/c++/v1 --with-pkgversion='MacPorts gcc13 13.2.0_3+stdlib_flag'
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 13.2.0 (MacPorts gcc13 13.2.0_3+stdlib_flag) 
COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-mmacosx-version-min=10.6.0' '-asm_macosx_version_min=10.6' '-nodefaultexport' '-mtune=core2'
 /opt/local/libexec/gcc/x86_64-apple-darwin10/13.2.0/cc1 -quiet -v -D__DYNAMIC__ test.c -fPIC -quiet -dumpbase test.c -dumpbase-ext .c -mmacosx-version-min=10.6.0 -mtune=core2 -version -o /var/tmp//ccijGkyC.s
GNU C17 (MacPorts gcc13 13.2.0_3+stdlib_flag) version 13.2.0 (x86_64-apple-darwin10)
	compiled by GNU C version 13.2.0, GMP version 6.2.1, MPFR version 4.2.1, MPC version 1.3.1, isl version isl-0.24-GMP

warning: GMP header version 6.2.1 differs from library version 6.3.0.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/opt/local/lib/gcc13/gcc/x86_64-apple-darwin10/13.2.0/../../../../../x86_64-apple-darwin10/include"
#include "..." search starts here:
#include <...> search starts here:
 /opt/local/lib/gcc13/gcc/x86_64-apple-darwin10/13.2.0/include
 /opt/local/include
 /opt/local/lib/gcc13/gcc/x86_64-apple-darwin10/13.2.0/include-fixed
 /usr/include
 /System/Library/Frameworks
 /Library/Frameworks
End of search list.
Compiler executable checksum: 5959dc55c979e6aef969f388840a1ac3
COLLECT_GCC_OPTIONS='-o' 'test' '-v' '-mmacosx-version-min=10.6.0'  '-nodefaultexport' '-mtune=core2'
 /opt/local/bin/as -arch x86_64 -v -mmacosx-version-min=10.6 -force_cpusubtype_ALL -o /var/tmp//ccnoLCUL.o /var/tmp//ccijGkyC.s
Apple Inc version cctools-localbuild, GNU assembler version 1.38
FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
snow-leopard:tmp catap$ 

Similar issue appears on all gcc since gcc8.

snow-leopard:tmp catap$ gcc-mp-7 -o test test.c
snow-leopard:tmp catap$ gcc-mp-8 -o test test.c
FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
snow-leopard:tmp catap$ gcc-mp-9 -o test test.c
FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
snow-leopard:tmp catap$ gcc-mp-10 -o test test.c
FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
snow-leopard:tmp catap$ gcc-mp-11 -o test test.c
FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
snow-leopard:tmp catap$ gcc-mp-12 -o test test.c
FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
snow-leopard:tmp catap$ gcc-mp-13 -o test test.c
FATAL:/opt/local/bin/../libexec/as/x86_64/as: I don't understand 'm' flag!
snow-leopard:tmp catap$ 

[kencu (Ken)]

if you install any macports-clang newer than clang-5.0 you should be good to go.

[catap (Kirill A. Korinsky)]

Ken, should be it installed by dependency as well to avoid such unexpected behaviour?

I've found it by investigating why ecl ports are failed on build bot.

[kencu (Ken)]

we have talked about doing that.

If gcc8+ won’t run at all any more without it, it makes sense to me.

[catap (Kirill A. Korinsky)]

It haven’t run on trivial case on clean system nor build bot.

[kencu (Ken)]

I believe what happens is that the gcc build tests what features the assembler supports during configure.

As currently some newer macports-clang is present during the gcc build these days, gcc’s configure sees that flag as supported.

Later, if you try to run gcc without any macports-clang, the old ‘gas ‘ assembler is used and as you point out, it fails.

You’ll have to think about which systems should have a dependency added, and which clang should be added.

Some gccs already add a clang dep to support libc++ I believe, so take that into consideration too when you decide.

[catap (Kirill A. Korinsky)]

Honeslty I don't think it is wise to add dependency from gcc to clang.

The root cause of issue that behaviour of /opt/local/bin/as depends on which clang is installed. It is incinsistent and ctools should requires "some clang" and not "some LLVM" like it does right now.

[kencu (Ken)]

bootstrapping the toolchain is always fun -- currently cctools can't depend on any clang, due to circular deps.

eventually somebody will set up a proper toolchain plan, using clang-11-bootstrap to build the most modern toolchains it can build on all older systems.

[catap (Kirill A. Korinsky)]

Replying to kencu:

eventually somebody will set up a proper toolchain plan, using clang-11-bootstrap to build the most modern toolchains it can build on all older systems.

I already started work, but testing requires significant amount of time which I'm trying to allocate to finish that.

[catap (Kirill A. Korinsky)]

In d0e6ec59be9c26d232fede065a77f2835c026973/macports-ports (master):

gcc7+: enforce using system as

Since GCC 7.4.0, during configure, it detects features supported by target-as.
On the other hand, MacPorts cctools contain a proxy for as that runs system
as or one of the supported MacPorts clang's as if it is installed. Here,
we may encounter a misconfiguration when GCC builds on a system with some
MacPorts clang, and as is using it. However, on a clean system, it uses
system as if no MacPorts clang is installed, which may behave differently.
This can make GCC broken until MacPorts clang is installed. To avoid a stealth
dependency on the used clang, I enforce building with system as.

See: ​https://github.com/gcc-mirror/gcc/commit/b410cf1dc056aab195c5408871ffca932df8a78a
Closes: #68683

[skip ci]