https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87836
--- Comment #29 from ro at CeBiTec dot Uni-Bielefeld.DE <ro at CeBiTec dot Uni-Bielefeld.DE> --- > --- 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 Good. > 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 The gcc build is careful to both build the compilers with -static-libgcc -static-libstdc++ just to avoid unexpected uses of preinstalled gcc runtime libs. On top of that, LD_LIBRARY_PATH and friends are set during the build and make check phases to make sure only the freshly built libs are used. Still, it's certainly safer to use a prefix that is either empty or nonexistant to avoid interference. > 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. Of the configure options used in Comment #23, CFLAGS= -O3 -mno-app-regs seems somewhat dubious. You might just be triggering a bug in the bootstrap gcc 4.9, which IIUC has quite a number of Illumos-specific patches. > 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. This is fully expected: since we are before building the crt files, link tests cannot work, and libgcc/configure is careful to run its tests in a way that don't require them (e.g. with -nostartfiles -nodefaultlibs).
