https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #28 from Gary Mills <gary_mills at fastmail dot fm> --- I installed the patch mentioned above to bypass that error. Now, with this minimal configuration: $ /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/gcc-7.3.0/configure --without-gnu-ld --with-ld=/usr/bin/ld --without-gnu-as --with-as=/usr/bin/as I got a successful build. Still, we are not quite at the root cause. This result does suggest that something in the previous configuration caused the ICE. Note that /usr/local, the default prefix, does not exist. Also, /usr/gcc/7, the desired prefix, does not exist. I'm going to try to re-introduce some of the previous configuration to identify what causes the ICE. This will take some time, as each build takes about three days. Any suggestions about the culprit in the previous configuration will be appreciated. I do see this error in all six copies of libgcc/config.log: configure:3471: /export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/xgcc -B/export/home/mills/Downloads/code/oi-userland/components/developer/gcc-7/build/sparcv7/./gcc/ -B/usr/local/sparc-sun-solaris2.11/bin/ -B/usr/local/sparc-sun-solaris2.11/lib/ -isystem /usr/local/sparc-sun-solaris2.11/include -isystem /usr/local/sparc-sun-solaris2.11/sys-include -o conftest -g -O2 conftest.c >&5 ld: fatal: file crtp.o: open failed: No such file or directory ld: fatal: file crtbegin.o: open failed: No such file or directory ld: fatal: file crtend.o: open failed: No such file or directory ld: fatal: file processing errors. No output written to conftest collect2: error: ld returned 1 exit status configure:3474: $? = 1 configure:3662: checking for suffix of object files It happens because the configure script ran before the crt*.o files had been created. Here's an example of the timestamps: -rw-r--r-- 1 mills staff 504 Jan 7 05:43 build/sparcv7/gcc/crtp.o -rw-r--r-- 1 mills staff 60825 Jan 7 05:38 build/sparcv7/sparc-sun-solaris2.11/libgcc/config.log As far as I can tell, a failure of the linker at this point tells the script that we are cross-compiling, and bypasses any subsequent tests that require the linker. I don't know what effect these assumptions might have.
