It fails while building libstdc++ in stage1, with the following error: /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/./gcc/xgcc -shared-libgcc -B/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/./gcc -nostdinc++ -L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src -L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs -L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs -B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/bin/ -B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/lib/ -isystem /usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/include -isystem /usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/sys-include -x c++-header -nostdinc++ -g -O2 -I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include -I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h \ -o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/./gcc/xgcc -shared-libgcc -B/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/./gcc -nostdinc++ -L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src -L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs -L/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs -B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/bin/ -B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/lib/ -isystem /usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/include -isystem /usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/sys-include -x c++-header -nostdinc++ -g -O2 -I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include -I/private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/libsupc++ -O2 -g /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch In file included from /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/ios:39:0, from /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/istream:38, from /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/sstream:38, from /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/complex:45, from /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/ccomplex:39, from /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h:52: /private/tmp/gcc-20170809-5279-vvhneo/gcc-7.1.0/libstdc++-v3/libsupc++/exception:143:10: fatal error: bits/nested_exception.h: No such file or directory #include <bits/nested_exception.h> ^~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[5]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch] Error 1 This is configured with ../configure --build=x86_64-apple-darwin17.0.0 --prefix=/usr/local/Cellar/gcc/7.1.0 --libdir=/usr/local/Cellar/gcc/7.1.0/lib/gcc/7 --enable-languages=c,c++,objc,obj-c++,fortran,jit --program-suffix=-7 --with-system-zlib --enable-checking=release --with-nls --enable-host-shared Full output of compilation is there: https://gist.githubusercontent.com/shatteringlass/21fb3c03bf39931fa7be9d698413282f/raw/d19a4945946afdcf42370abd93018fa80c949a2f/02.make
I don't see how this can happen, that header is present in the libstdc++ source tree and there's nothing target-specific about it.
Do you have the file $target/libstdc++-v3/include/stamp-bits-sup ?
I'm seeing a similar failure, also on macOS 10.13. I can only reproduce when macOS is installed on an APFS filesystem, not HFS+. The issue occurs intermittently, and the specific header that libstdc++ fails to find varies from run to run. /private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/./gcc/xgcc -shared-libgcc -B/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/./gcc -nostdinc++ -L/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src -L/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs -L/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs -B/usr/local/Cellar/gcc/7.2.0/x86_64-apple-darwin17.0.0/bin/ -B/usr/local/Cellar/gcc/7.2.0/x86_64-apple-darwin17.0.0/lib/ -isystem /usr/local/Cellar/gcc/7.2.0/x86_64-apple-darwin17.0.0/include -isystem /usr/local/Cellar/gcc/7.2.0/x86_64-apple-darwin17.0.0/sys-include -x c++-header -nostdinc++ -g -O2 -I/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include -I/private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/libstdc++-v3/libsupc++ -O2 -g /private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch In file included from /private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/sstream:38:0, from /private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/complex:45, from /private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/ccomplex:39, from /private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h:52: /private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17.0.0/libstdc++-v3/include/istream:38:10: fatal error: ios: No such file or directory #include <ios> ^~~~~ I can confirm that $target/libstdc++-v3/include/ios exists.
Redoing lost comments: https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01294.html Jack Howarth <howarth.at.gcc at gmail dot com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |howarth.at.gcc at gmail dot com --- Comment #3 from Jack Howarth <howarth.at.gcc at gmail dot com> --- I don't see this issue with the gcc7-7.1.0-1 fink package build on High Sierra. This is from a clean install of fink master on 10.13 using the proposed changes from... https://github.com/fink/fink/pull/143 to bootstrap fink git master on 10.13 and patching all the fink package dependencies that trip over the increased format string strictness in 10.13... http://lists.gnu.org/archive/html/bug-gnulib/2017-07/msg00056.html https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01310.html Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Last reconfirmed| |2017-08-13 Ever confirmed|0 |1 --- Comment #4 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- We have a Homebrew user report it, and I can see it myself. It is intermittent, and I have seen it happen twice, always with "make -j4" (2 out of 4 parallel builds). Building with -j1 does not appear to trigger the issue. https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01311.html --- Comment #5 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- I've also found one case where the error is slightly different (also "make -j4"): make "AR_FLAGS=rc" "CC_FOR_BUILD=clang" "CC_FOR_TARGET=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/xgcc -B/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/" "CFLAGS=-g -O2 -m32" "CXXFLAGS=-g -O2 -m32" "CFLAGS_FOR_BUILD=-g -O2" "CFLAGS_FOR_TARGET=-g -O2" "INSTALL=/usr/bin/install -c" "INSTALL_DATA=/usr/bin/install -c -m 644" "INSTALL_PROGRAM=/usr/bin/install -c" "INSTALL_SCRIPT=/usr/bin/install -c" "LDFLAGS=-m32" "LIBCFLAGS=-g -O2 -m32" "LIBCFLAGS_FOR_TARGET=-g -O2" "MAKE=make" "MAKEINFO=makeinfo --split-size=5000000 --split-size=5000000 --split-size=5000000 " "SHELL=/bin/sh" "RUNTESTFLAGS=" "exec_prefix=/usr/local/Cellar/gcc/7.1.0" "infodir=/usr/local/Cellar/gcc/7.1.0/share/info" "libdir=/usr/local/Cellar/gcc/7.1.0/lib/gcc/7" "includedir=/usr/local/Cellar/gcc/7.1.0/include" "prefix=/usr/local/Cellar/gcc/7.1.0" "tooldir=/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0" "gxx_include_dir=/usr/local/Cellar/gcc/7.1.0/include/c++/7.1.0" "AR=ar" "AS=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/as" "LD=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/collect-ld" "RANLIB=ranlib" "NM=/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/nm" "NM_FOR_BUILD=" "NM_FOR_TARGET=nm" "DESTDIR=" "WERROR=" all-recursive Making all in include mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch /private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/xgcc -shared-libgcc -B/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc -nostdinc++ -L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src -L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src/.libs -L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/libsupc++/.libs -B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/bin/ -B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/lib/ -isystem /usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/include -isystem /usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/sys-include -m32 -x c++-header -nostdinc++ -g -O2 -m32 -I/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include -I/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/libstdc++-v3/libsupc++ -O2 -g -std=gnu++0x /private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h \ -o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch /private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc/xgcc -shared-libgcc -B/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/./gcc -nostdinc++ -L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src -L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src/.libs -L/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/libsupc++/.libs -B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/bin/ -B/usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/lib/ -isystem /usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/include -isystem /usr/local/Cellar/gcc/7.1.0/x86_64-apple-darwin17.0.0/sys-include -m32 -x c++-header -nostdinc++ -g -O2 -m32 -I/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/build/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include -I/private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/libstdc++-v3/libsupc++ -O2 -g /private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch /private/tmp/gcc-20170813-56216-v7ncm/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h:56:10: fatal error: cstdbool: No such file or directory #include <cstdbool> ^~~~~~~~~~ compilation terminated. make[9]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch] Error 1 After make aborts, the contents of the include folders in that build are: bash-3.2$ ls x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/ Makefile complex experimental numeric stamp-debug string algorithm complex.h ext optional stamp-decimal string_view any condition_variable fenv.h ostream stamp-dual-abi system_error array csetjmp forward_list parallel stamp-experimental tgmath.h atomic csignal fstream profile stamp-experimental-bits thread backward cstdalign functional queue stamp-ext tr1 bits cstdarg future random stamp-extern-template tr2 bitset cstdbool gstdint.h ratio stamp-host tuple cassert cstddef iomanip regex stamp-namespace-version type_traits ccomplex cstdint ios scoped_allocator stamp-parallel typeindex cctype cstdio iosfwd set stamp-pb unordered_map cerrno cstdlib iostream shared_mutex stamp-profile unordered_set cfenv cstring istream sstream stamp-profile-impl utility cfloat ctgmath iterator stack stamp-std valarray chrono ctime limits stamp-allocator-new stamp-tr1 variant cinttypes cuchar list stamp-backward stamp-tr2 vector ciso646 cwchar locale stamp-bits stamp-visibility x86_64-apple-darwin17.0.0 climits cwctype map stamp-bits-sup stamp-x86_64-apple-darwin17.0.0 clocale debug math.h stamp-c_base stdexcept cmath decimal memory stamp-c_compatibility stdlib.h codecvt deque mutex stamp-cxx11-abi streambuf bash-3.2$ ls x86_64-apple-darwin17.0.0/libstdc++-v3/include Makefile complex experimental numeric stamp-debug string algorithm complex.h ext optional stamp-decimal string_view any condition_variable fenv.h ostream stamp-dual-abi system_error array csetjmp forward_list parallel stamp-experimental tgmath.h atomic csignal fstream profile stamp-experimental-bits thread backward cstdalign functional queue stamp-ext tr1 bits cstdarg future random stamp-extern-template tr2 bitset cstdbool gstdint.h ratio stamp-host tuple cassert cstddef iomanip regex stamp-namespace-version type_traits ccomplex cstdint ios scoped_allocator stamp-parallel typeindex cctype cstdio iosfwd set stamp-pb unordered_map cerrno cstdlib iostream shared_mutex stamp-profile unordered_set cfenv cstring istream sstream stamp-profile-impl utility cfloat ctgmath iterator stack stamp-std valarray chrono ctime limits stamp-allocator-new stamp-tr1 variant cinttypes cuchar list stamp-backward stamp-tr2 vector ciso646 cwchar locale stamp-bits stamp-visibility x86_64-apple-darwin17.0.0 climits cwctype map stamp-bits-sup stamp-x86_64-apple-darwin17.0.0 clocale debug math.h stamp-c_base stdexcept cmath decimal memory stamp-c_compatibility stdlib.h codecvt deque mutex stamp-cxx11-abi streambuf I am not sure what other information I can pass on… https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01312.html --- Comment #6 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- (On both macOS 10.12 and 10.13, make is "GNU Make 3.81". But I have never seen that bug on 10.12, and it's not been reported by any Homebrew user.) https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01313.html --- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- Yet another one: In file included from /Users/fx/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/bits/stl_algo.h:62:0, from /Users/fx/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/algorithm:62, from /Users/fx/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h:65: /Users/fx/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/bits/stl_tempbuf.h:60:10: fatal error: bits/stl_construct.h: No such file or directory #include <bits/stl_construct.h> ^~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[5]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch] Error 1 Yet when make aborts, the file x86_64-apple-darwin17.0.0/libstdc++-v3/include/bits/stl_construct.h is present. So I guess it's a race condition somewhere in the Makefile. https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01314.html --- Comment #8 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- Can reproduce with GNU Make 4.2.1, on the same system. https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01315.html --- Comment #9 from Jack Howarth <howarth.at.gcc at gmail dot com> --- (In reply to Francois-Xavier Coudert from comment #8) > Can reproduce with GNU Make 4.2.1, on the same system. I assume all of these builds are done using a gcc7.rb file run under ruby, correct? You might try a manual build outside of ruby (but duplicating there exact build approach). There is a history of certain race condition bugs only being exposed when make is run under a particular program... http://savannah.gnu.org/bugs/index.php?46261 https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01316.html --- Comment #10 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- (In reply to Jack Howarth from comment #9) No, I can reproduce this with a build outside Homebrew/ruby. From the command line: $ ../gcc-7.1.0/configure --build=x86_64-apple-darwin17.0.0 --prefix=/usr/local/Cellar/gcc/7.1.0 --with-gmp=/usr/local/opt/gmp --with-mpfr=/usr/local/opt/mpfr --with-mpc=/usr/local/opt/libmpc --with-isl=/usr/local/opt/isl --enable-checking=release --with-native-system-header-dir=/usr/include --with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.13.sdk $ make -j4 The only thing I can think of is that maybe, just maybe, it's due to filesystem timestamp granularity? My 10.13 system is running on APFS filesystem, which has 1 ns granularity (smaller than 1 s for HFS+). https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01318.html --- Comment #11 from Jack Howarth <howarth.at.gcc at gmail dot com> --- (In reply to Francois-Xavier Coudert from comment #10) > (In reply to Jack Howarth from comment #9) > > > The only thing I can think of is that maybe, just maybe, it's due to > filesystem timestamp granularity? My 10.13 system is running on APFS > filesystem, which has 1 ns granularity (smaller than 1 s for HFS+). That sounds much more likely as the trigger for the problem. I only have hard drives to test 10.13 on so I am stuck with HFS (and wouldn't press the envelope with APFS without using it on an SSD). https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01319.html --- Comment #12 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- (In reply to Francois-Xavier Coudert from comment #10) > The only thing I can think of is that maybe, just maybe, it's due to > filesystem timestamp granularity? My 10.13 system is running on APFS > filesystem, which has 1 ns granularity (smaller than 1 s for HFS+). Some potential confirmation of this: compiling with the 10.12 Xcode 8 on the 10.13 machine with APFS leads to the same error. Another difference between HFS+ and APFS is file ordering: “Calling readdir(2) on a directory in APFS returns filenames in hash order, whereas HFS+ returns filenames in lexicographical order.” https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01320.html --- Comment #13 from Jack Howarth <howarth.at.gcc at gmail dot com> --- (In reply to Francois-Xavier Coudert from comment #12)> > Some potential confirmation of this: compiling with the 10.12 Xcode 8 on the > 10.13 machine with APFS leads to the same error. > > Another difference between HFS+ and APFS is file ordering: “Calling > readdir(2) on a directory in APFS returns filenames in hash order, whereas > HFS+ returns filenames in lexicographical order.” It might be an interesting exercise to encrypt the APFS volume and see if that throws just enough additional filesystem overhead in to make the problem go latent. https://gcc.gnu.org/ml/gcc-bugs/2017-08/msg01569.html Jonathan Wakely <redi at gcc dot gnu.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |build Target| |x86_64-apple-darwin17.0.0 Component|libstdc++ |target Host| |x86_64-apple-darwin17.0.0 Build| |x86_64-apple-darwin17.0.0 --- Comment #14 from Jonathan Wakely <redi at gcc dot gnu.org> --- I'm changing the component, because I don't think this is a libstdc++ issue.
Same bug exists with GCC 7.2.0 and GCC 6.4.0, when compiled on a APFS filesystem.
Hi, > It might be an interesting exercise to encrypt the APFS volume and see if that throws just enough additional filesystem overhead in to make the problem go latent. I'm also trying to compile gcc-7.2.0 on macOS 10.13, and I'm using encrypted APFS, but it does not make this bug disappear. Regards, Romain
(In reply to Romain from comment #6) > Hi, > > > It might be an interesting exercise to encrypt the APFS volume and see if that > throws just enough additional filesystem overhead in to make the problem go > latent. > > I'm also trying to compile gcc-7.2.0 on macOS 10.13, and I'm using encrypted > APFS, but it does not make this bug disappear. > > Regards, > Romain FX and Romain, How many cores does each of your build systems have? Jeremy Sequoia says he hasn't seen this on any of his build systems with APFS for MacPorts gcc6 or later bootstraps but he is using 4 core systems in each case. I have seen instances where particular race conditions don't show up on 8 core systems but plague dual core systems.
Hi Jack, Thanks. My system is a Core i7 (HT enabled), so I have 8 cores, good catch! Regards, Romain
My VM has two cores, and repros this problem. I reported this to Apple, who assigned the bug ID rdar://33924943. It was reported to me that Apple engineers believed it was fixed in the latest beta, but it is still reproducing.
I managed to reproduce this issue on an 8 core non-HT system booted from an APFS volume on an old SATA2 HDD so the issue doesn't seem to be dependent on really fast IO... Making all in include mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch mkdir -p ./x86_64-apple-darwin17.0.0/bits/stdc++.h.gch /sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/src -L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs -B/sw/lib/gcc7/x86_64-apple-darwin17.0.0/bin/ -B/sw/lib/gcc7/x86_64-apple-darwin17.0.0/lib/ -isystem /sw/lib/gcc7/x86_64-apple-darwin17.0.0/include -isystem /sw/lib/gcc7/x86_64-apple-darwin17.0.0/sys-include -x c++-header -nostdinc++ -g -O2 -I/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/include -I/sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/libsupc++ -I/sw/include -O2 -g -std=gnu++0x /sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h \ -o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch /sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/./gcc/xgcc -shared-libgcc -B/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/./gcc -nostdinc++ -L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/src -L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/src/.libs -L/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/libsupc++/.libs -B/sw/lib/gcc7/x86_64-apple-darwin17.0.0/bin/ -B/sw/lib/gcc7/x86_64-apple-darwin17.0.0/lib/ -isystem /sw/lib/gcc7/x86_64-apple-darwin17.0.0/include -isystem /sw/lib/gcc7/x86_64-apple-darwin17.0.0/sys-include -x c++-header -nostdinc++ -g -O2 -I/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/sw/src/fink.build/gcc7-7.2.0-1/darwin_objdir/x86_64-apple-darwin17.0.0/libstdc++-v3/include -I/sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/libsupc++ -I/sw/include -O2 -g /sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch /sw/src/fink.build/gcc7-7.2.0-1/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h:35:10: fatal error: cctype: No such file or directory #include <cctype> ^~~~~~~~ compilation terminated. make[5]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch] Error 1 make[5]: *** Waiting for unfinished jobs.... make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[1]: *** [stage1-bubble] Error 2
For what it's worth, I managed to partially suppress the missing headers bootstrap failure for libstdc++-v3 with the change... ++-v3/include/Makefile.in --- libstdc++-v3/include/Makefile.in.orig 2017-08-29 22:22:17.000000000 -0400 +++ libstdc++-v3/include/Makefile.in 2017-08-29 20:06:57.000000000 -0400 @@ -1761,7 +1761,7 @@ # host_headers_extra are taken out of the build tree staging area; # the rest are taken from the original source tree. -@GLIBCXX_HOSTED_TRUE@install-data-local: install-headers +@GLIBCXX_HOSTED_TRUE@install-data-local: install-freestanding-headers @GLIBCXX_HOSTED_FALSE@install-data-local: install-freestanding-headers # This is a subset of the full install-headers rule. We only need <ciso646>, However this change just moves the missing header error from stage1 to stage2.
Just to add in things that don't fix these failures, the following doesn't help... --- gcc-7.2.0/libstdc++-v3/include/Makefile.in.orig 2017-09-02 11:00:08.000000000 -0400 +++ gcc-7.2.0/libstdc++-v3/include/Makefile.in 2017-09-02 11:12:38.000000000 -0400 @@ -1887,16 +1887,37 @@ # developer tries to create them via make in the include build # directory. (This is more of an example of how this kind of rule can # be made.) -.PRECIOUS: $(std_headers) $(c_base_headers) $(tr1_headers) $(tr2_headers) +.PRECIOUS: $(std_headers) $(bits_headers) $(c_base_headers) $(tr1_headers) $(tr2_headers) $(decimal_headers) $(ext_headers) $(experimental_headers) - $(experimental_bits_headers) + $(experimental_bits_headers) $(bits_host_headers) $(bits_sup_headers) + $(backward_headers) $(ext_compat_headers) $(ext_host_headers) + $(experimental_filesystem_headers) $(experimental_bits_filesystem_headers) + $(c_compatibility_headers) $(debug_headers) $(parallel_headers) + $(profile_headers) $(profile_impl_headers) $(host_headers) $(thread_host_headers) $(std_headers): ; @: +$(bits_headers): ; @: +$(bits_host_headers): ; @: +$(bits_sup_headers): ; @: +$(backward_headers): ; @: $(c_base_headers): ; @: $(tr1_headers): ; @: +$(tr2_headers): ; @: $(decimal_headers): ; @: $(ext_headers): ; @: +$(ext_compat_headers): ; @: +$(ext_host_headers): ; @: $(experimental_headers): ; @: $(experimental_bits_headers): ; @: +$(experimental_filesystem_headers): ; @: +$(experimental_bits_filesystem_headers): ; @: +$(c_compatibility_headers): ; @: +$(debug_headers): ; @: +$(parallel_headers): ; @: +$(profile_headers): ; @: +$(profile_impl_headers): ; @: +$(host_headers): ; @: +$(thread_host_headers): ; @: + # Tell versions [3.59,3.63) of GNU make to not export all variables. # Otherwise a system limit (for SysV at least) may be exceeded.
The following hack allows gcc 7.2.0 to complete the 3 stage bootstrap of the c,c++,fortran,lto,objc,obj-c++ language set under High Sierra on an APFS volume... diff -uNr gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in gcc-7.2.0/libstdc++-v3/include/Makefile.in --- gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in 2017-07-25 14:05:07.000000000 -0400 +++ gcc-7.2.0/libstdc++-v3/include/Makefile.in 2017-09-02 12:22:08.000000000 -0400 @@ -1764,6 +1764,8 @@ @GLIBCXX_HOSTED_TRUE@install-data-local: install-headers @GLIBCXX_HOSTED_FALSE@install-data-local: install-freestanding-headers +.NOTPARALLEL: install-headers + # This is a subset of the full install-headers rule. We only need <ciso646>, # <cstddef>, <cfloat>, <limits>, <climits>, <cstdint>, <cstdlib>, <new>, # <typeinfo>, <exception>, <initializer_list>, <cstdalign>, <cstdarg>,
Thank you Jack, gcc-7.2.0 now compiles correctly on my i7 system (8 cores HT) with encrypted APFS Best regards
Maybe I'm just thick, but from the generated x86_64-apple-darwin17.0.0/libstdc++-v3/include/Makefile, it is entirely unclear to me how the stamp mechanism and the current install-headers insures that install-headers has completed in its entirety. The way I read the current Makefile is that it is merely checking for the existence of the include subdirectories having been installed and not that that they have been completely populated. Looks like a broken implementation of stamps to me.
The component on this bug should probably be switched back off of 'target' to 'libstdc++' as the broken stamps implementation is likely just latent on other targets because none of them have filesystems with the fine time granularity of APFS yet,
I see the same issue when building tools for RTEMS using the RSB. I have collected the posted parts in a patch and attached it to a ticket in RTEMS's trac: https://devel.rtems.org/ticket/3171 An RTEMS tools build now fails with: ../../../../gcc-7.2.0/libstdc++-v3/libsupc++/atexit_thread.cc:27:10: fatal error: bits/gthr.h: No such file or directory #include "bits/gthr.h" ^~~~~~~~~~~~~ so there seems to be more issues.
Definitely not "target" if it is seen on other platforms too. Adding ".NOTPARALLEL: install-headers" to the libstdc++ Makefile fixes it perfectly, from what we can see on our apple-darwin test machines. We've now had dozens of compilations of GCC with no error, once that is applied. Without the patch, about ~70% of parallel compilations fail, on machines ranging from 2 to 8 cores. I'd like to suggest ".NOTPARALLEL: install-headers" to be considered as official patch.
(In reply to Francois-Xavier Coudert from comment #18) > Adding ".NOTPARALLEL: install-headers" to the libstdc++ Makefile fixes it > perfectly, from what we can see on our apple-darwin test machines. We've now > had dozens of compilations of GCC with no error, once that is applied. > Without the patch, about ~70% of parallel compilations fail, on machines > ranging from 2 to 8 cores. Are you able to try an RTEMS tools build? It is a cross-compiler so I am wondering if there is something still not right in this case. I can push my changes to the RTEMS Source Builder tool we use to build tools and post or send instructions. > I'd like to suggest ".NOTPARALLEL: install-headers" to be considered as > official patch. The other solution is to unroll the shell loops and create the dependences. I had to do this in RTEMS to get preinstalled headers to work. Chris
I have been testing the patch attached to RTEMS ticket https://devel.rtems.org/ticket/3171 and it has built gcc once for ARM and then it did not build for SPARC plus SPARC build can fail on different header files.
I can confirm that this affects the latest gcc-8 snapshot (20170715) on High Sierra with an APFS encrypted volume, and that adding ".NOTPARALLEL: allcreated install-headers install-freestanding-headers" to libstdc++-v3/include/Makefile.in resolves it.
So maybe somebody should submit the patch to the mailing lists.
(In reply to Jonathan Wakely from comment #22) > So maybe somebody should submit the patch to the mailing lists. Submitted: https://gcc.gnu.org/ml/libstdc++/2017-10/msg00045.html Sorry I didn't do it before, but I wasn't sure it would be welcome, as you were (as far as I can tell) the only libstdc++ maintainer to have commented here, and you had stated that you "don't think this is a libstdc++ issue".
I would welcome a patch attached to this ticket. My efforts with .NOTPARALLEL cannot get RTEMS's cross-compiled tools to build. I have seen a build work however most fail with a range of headers that can vary from build to build. I can see the massive `ln -s` happening and after the build fails and stops all the links are present.
(In reply to Chris Johns from comment #24) > I would welcome a patch attached to this ticket. > > My efforts with .NOTPARALLEL cannot get RTEMS's cross-compiled tools to > build. I have seen a build work however most fail with a range of headers > that can vary from build to build. I can see the massive `ln -s` happening > and after the build fails and stops all the links are present. Doesn't cross-compiles set GLIBCXX_HOSTED_FALSE such that install-data-local is set to install-freestanding-headers instead of install-headers in libstdc++-v3/include/Makefile.in? Perhaps you need... .NOTPARALLEL: install-freestanding-headers as well?
No, cross-compiles are not automatically freestanding, and .NOTPARALLEL ignores any prerequisites, so it makes no difference whether you say .NOTPARALLEL: install-freestanding-headers or .NOTPARALLEL: install-headers or .NOTPARALLEL: they all have the same effect.
(In reply to Jack Howarth from comment #25) > (In reply to Chris Johns from comment #24) > Doesn't cross-compiles set GLIBCXX_HOSTED_FALSE such that install-data-local > is set to install-freestanding-headers instead of install-headers in > libstdc++-v3/include/Makefile.in? Perhaps you need... > > .NOTPARALLEL: install-freestanding-headers > > as well? I tried a number of options when looking and also I thought all that was needed was .NOTPARALLEL:. I will boot up the Mac and take look soon. I looked over the include's Makefile.in and I am still a little confused about the race-condition being patched with .NOTPARALLEL. I could not see one, which is not unusual with this type of issue. The failure for me is always in a header the massive 'ln -s' as I stated before and this is part of the 'all' target being invoked at this point in time yet it is a C++ file being built by some other Makefile that is seeing the file not present and when I inspect the directory after the failure the link is present. Is the race condition or failure somewhere else?
I am also failing to see how this can happen without a bug in make or macos. The failing command is the recipe for ${pch1b_output}. That rule has ${allstamped} as a dependency, which includes stamp-bits-sup, whose recipe does link the header. At least, disabling precompiled headers should work around it (--disable-libstdcxx-pch IIRC) You could always remove the @ sign on the $(STAMP) lines (and the ones before) so it gets printed in the output, maybe that would show something suspicious. If you are building in a clean directory (the headers aren't there yet), you could also remove '-' at the beginning of the $(LN_S) lines, to make sure that no error occurs. Running make in verbose mode might also hint at something. Maybe print the date in the pch rule (or use the creation date of ${pch1_output_builddir}), and compare it to the creation date of the symlinks, etc. If the issue was with make, you could try replacing all-local: ${allstamped} ${allcreated} with all-local: $(MAKE) ${allstamped} $(MAKE) ${allcreated} Generally, I don't understand why we are linking sources in the build directory instead of passing -I flags pointing directly to the source directory.
As suggested by Marc, I've removed the @ from include/Makefile.in, and removed the leading - for lines with LN_S. The result of "make -d --trace -j8 all-target-libstdc++-v3", in a build where x86_64-apple-darwin17.0.0/libstdc++-v3 was entirely removed, can be found here: https://gist.github.com/fxcoudert/b621465a794d968593bc7ed90c0fc1fb
(In reply to Francois-Xavier Coudert from comment #29) > The result of "make -d --trace -j8 all-target-libstdc++-v3", in a build > where x86_64-apple-darwin17.0.0/libstdc++-v3 was entirely removed, can be > found here: > https://gist.github.com/fxcoudert/b621465a794d968593bc7ed90c0fc1fb make's I/O is not exactly a reliable way to debug multithreading issues, but the output looks right to me. If --disable-libstdcxx-pch works (does it?), and until someone can investigate more, I'd be tempted to consider it a mac bug and recommend that option in https://gcc.gnu.org/install/specific.html .
> If --disable-libstdcxx-pch works (does it?), and until someone can investigate more, I'd be tempted to consider it a mac bug and recommend that option in https://gcc.gnu.org/install/specific.html . For what it's worth, Apple's response was: "We analyzed the issue and determined the problem to be a latent bug in gcc’s build system that is revealed by changes in macOS High Sierra. The FSF will need up issue a fix in gcc."
(In reply to Misty De Meo from comment #31) > For what it's worth, Apple's response was: "We analyzed the issue and > determined the problem to be a latent bug in gcc’s build system that is > revealed by changes in macOS High Sierra. The FSF will need up issue a fix > in gcc." Thanks for forwarding. Their response is oh so precise and helpful... "bug on your side, washing my hands". I can't complain since I basically did the same thing in my previous comment, but if they really did analyze the issue, one might expect that they would share what the bug actually is :-(
(In reply to Marc Glisse from comment #28) > Generally, I don't understand why we are linking sources in the build > directory instead of passing -I flags pointing directly to the source > directory. I think it's because the directory structures and relative layout of files are different. The build dir contains symlinks to assemble the right set of files from various different dirs, like include/std and config/locale etc. into a single location.
(In reply to Jack Howarth from comment #15) > Maybe I'm just thick, but from the generated > x86_64-apple-darwin17.0.0/libstdc++-v3/include/Makefile, it is entirely > unclear to me how the stamp mechanism and the current install-headers > insures that install-headers has completed in its entirety. The install-headers target is for installing them in DESTDIR. Unless I'm miusunderstanding, the problem happens earlier, while building libstdc++, not when installing anything. > The way I read the current Makefile is that it is merely checking for the > existence of the include subdirectories having been installed and not that > that they have been completely populated. Looks like a broken implementation > of stamps to me. The stamp file is created after populating the directory with symlinks: stamp-bits: ${bits_headers} @-mkdir -p ${bits_builddir} @-cd ${bits_builddir} && $(LN_S) $? . 2>/dev/null @$(STAMP) stamp-bits Creating the PCH depends on all the stamp files: # Build two precompiled C++ includes, stdc++.h.gch/*.gch ${pch1a_output}: ${allstamped} ${host_builddir}/c++config.h ${pch1_source} -mkdir -p ${pch1_output_builddir} $(CXX) $(PCHFLAGS) $(AM_CPPFLAGS) -O2 -g -std=gnu++0x ${pch1_source} \ -o $@ So all the files in ${allstamped} will have been created, which means all the symlinks will be present (assuming no errors from the $(LN_S) command, which may not be a safe assumption). I don't see an obvious problem with the stamp files.
(In reply to Jonathan Wakely from comment #34) > So all the files in ${allstamped} will have been created, which means all > the symlinks will be present (assuming no errors from the $(LN_S) command, > which may not be a safe assumption). On this point, when FX removed the 2>/dev/null redirection there were no errors shown, and several people have confirmed that when the error happens the symlink *does* exist. What I haven't seen any confirmation of is whether the symlink actually points to the right file: (In reply to Misty De Meo from comment #3) > /private/tmp/gcc-20170815-16334-85805x/gcc-7.2.0/build/x86_64-apple-darwin17. > 0.0/libstdc++-v3/include/istream:38:10: fatal error: ios: No such file or > directory > #include <ios> > ^~~~~ > > I can confirm that $target/libstdc++-v3/include/ios exists. and: --- Comment #7 from Francois-Xavier Coudert <fxcoudert at gcc dot gnu.org> --- Yet another one: In file included from /Users/fx/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/bits/stl_algo.h:62:0, from /Users/fx/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/algorithm:62, from /Users/fx/gcc-7.1.0/libstdc++-v3/include/precompiled/stdc++.h:65: /Users/fx/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/bits/stl_tempbuf.h:60:10: fatal error: bits/stl_construct.h: No such file or directory #include <bits/stl_construct.h> ^~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[5]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch] Error 1 Yet when make aborts, the file x86_64-apple-darwin17.0.0/libstdc++-v3/include/bits/stl_construct.h is present. Can somebody confirm the links are not only present, but point to the relevant file in the source tree?
Also, this strongly suggests the problem for RTEMS is different: (In reply to Chris Johns from comment #24) > I would welcome a patch attached to this ticket. > > My efforts with .NOTPARALLEL cannot get RTEMS's cross-compiled tools to > build. I have seen a build work however most fail with a range of headers > that can vary from build to build. I can see the massive `ln -s` happening > and after the build fails and stops all the links are present. i.e. this *is* a target issue (and there should be a separate PR for RTEMS).
(In reply to Jonathan Wakely from comment #35) > Can somebody confirm the links are not only present, but point to the > relevant file in the source tree? It seems OK: In file included from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/ios:39:0, from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/istream:38, from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/sstream:38, from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/complex:45, from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/libstdc++-v3/include/ccomplex:39, from /Users/fx/devel/gcc/trunk/libstdc++-v3/include/precompiled/stdc++.h:52: /Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++/exception:143:10: fatal error: bits/exception_ptr.h: No such file or directory #include <bits/exception_ptr.h> ^~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[5]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch] Error 1 make[5]: *** Waiting for unfinished jobs.... make[4]: *** [all-recursive] Error 1 make[3]: *** [all] Error 2 make[2]: *** [all-stage1-target-libstdc++-v3] Error 2 make[1]: *** [stage1-bubble] Error 2 make: *** [all] Error 2 bli ~/devel/gcc/ibin $ ls -lh x86_64-apple-darwin17.0.0/libstdc++-v3/include/bits/exception_ptr.h lrwxr-xr-x 1 fx admin 64B Oct 25 15:29 x86_64-apple-darwin17.0.0/libstdc++-v3/include/bits/exception_ptr.h -> /Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++/exception_ptr.h
(In reply to Jonathan Wakely from comment #36) > Also, this strongly suggests the problem for RTEMS is different: > > (In reply to Chris Johns from comment #24) > > I would welcome a patch attached to this ticket. > > > > My efforts with .NOTPARALLEL cannot get RTEMS's cross-compiled tools to > > build. I have seen a build work however most fail with a range of headers > > that can vary from build to build. I can see the massive `ln -s` happening > > and after the build fails and stops all the links are present. > > > i.e. this *is* a target issue (and there should be a separate PR for RTEMS). I am not sure yet. If the .NOTPARALLEL does work and is suitable for integration I would have expected it to have worked for me. There is something happening I do not understand. FYI I do not see any build errors with the same version of MacOS on different hardware running HPFS. It is a different machine with a Fusion disk and that disk is not supported by APFS.
Using .NOTPARALLEL is definitely not an acceptable solution. **Maybe** using it for affected targets only would be acceptable. Using it for all targets is not.
(In reply to Chris Johns from comment #38) > FYI I do not see any build errors with the same version of MacOS on > different hardware running HPFS. It is a different machine with a Fusion > disk and that disk is not supported by APFS. Yes, the problem is known to be specific to APFS, due to the finer resolution of timestamps. Why is .NOTPARALLEL not an acceptable solution, until a more thorough solution is found? Is it actually possible to have an even reliably measurably longer build time due to .NOTPARALLEL? It fixes the problem, albeit in an overly conservative way. It would be much worse for it to continue to not work at all.
I requested a suggestion from Apple as to how to fix this, and was directed to the developer technical support page: https://developer.apple.com/support/technical/ Would you like me to file a support request, or would a GCC developer like to do that?
(In reply to Campbell from comment #40) > Yes, the problem is known to be specific to APFS, due to the finer > resolution of timestamps. Is it? Why should timestamp resolution cause ENOENT errors? I'm now testing this myself on a darwin system, and with some additional annotations in the Makefile I see this: GENERATING PCH x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch Jeu 26 oct 12:09:21 2017 /Users/fx/devel/gcc_trunk/libstdc++-v3/include/precompiled/stdc++.h:117:10: fatal error: unordered_map: No such file or directory #include <unordered_map> ^~~~~~~~~~~~~~~ compilation terminated. So the time just before starting the PCH compilation is 12:09:21, but the "missing" symlink has a timestamp 4 seconds earlier than that: % stat x86_64-apple-darwin17.0.0/libstdc++-v3/include/unordered_map 16777224 4818396244 lrwxr-xr-x 1 fx staff 0 64 "Oct 26 12:09:17 2017" "Oct 26 12:09:17 2017" "Oct 26 12:09:17 2017" "Oct 26 12:09:17 2017" 4194304 0 0 x86_64-apple-darwin17.0.0/libstdc++-v3/include/unordered_map How does a finer timestamp resolution mean that a symlink created 4 seconds ago is no longer readable? I think something else is going on here, and not a race condition in the makefile. > Why is .NOTPARALLEL not an acceptable solution, until a more thorough > solution is found? Is it actually possible to have an even reliably > measurably longer build time due to .NOTPARALLEL? It fixes the problem, > albeit in an overly conservative way. It would be much worse for it to > continue to not work at all. Because it's a hack that penalizes every target to paper over a problem that is only affecting one target. If we make that change I seriously doubt anybody's ever going to revisit the issue to solve it properly. This would be more acceptable: diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index 270dcbaf723..b14bb1ed79d 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -467,6 +467,12 @@ AM_CONDITIONAL(BUILD_PDF, test $ac_cv_prog_DBLATEX = "yes" && test $ac_cv_prog_PDFLATEX = "yes") +case "$build" in + *-*-darwin* ) glibcxx_include_dir_notparallel=yes ;; + * ) glibcxx_include_dir_notparallel=no ;; +esac +AM_CONDITIONAL(INCLUDE_DIR_NOTPARALLEL, + test $glibcxx_include_dir_notparallel = "yes") # Propagate the target-specific source directories through the build chain. ATOMICITY_SRCDIR=config/${atomicity_dir} diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am index 2c4d193d0a4..1479679705a 100644 --- a/libstdc++-v3/include/Makefile.am +++ b/libstdc++-v3/include/Makefile.am @@ -1479,3 +1479,7 @@ $(decimal_headers): ; @: $(ext_headers): ; @: $(experimental_headers): ; @: $(experimental_bits_headers): ; @: +if INCLUDE_DIR_NOTPARALLEL +# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 +.NOTPARALLEL: +endif
(In reply to Misty De Meo from comment #41) > I requested a suggestion from Apple as to how to fix this, and was directed > to the developer technical support page: > https://developer.apple.com/support/technical/ Would you like me to file a > support request, or would a GCC developer like to do that? It would be great if you could do so, thanks.
(In reply to Jonathan Wakely from comment #42) > I think something else is going on here, and not a race condition in the > makefile. I agree. I see the failure after a few files have been built. > > This would be more acceptable: > I tried this change and it did not fix the issue for me. The patch I used on gcc-7.2.0 is: https://devel.rtems.org/attachment/ticket/3171/darwin-apfs-gcc-libstdc%2B%2B-bug-81797-redi-2.diff
This simple hack as a test works for me with `-j 8` on an i7 without .NOTPARALLEL: --- gcc-7.2.0/libstdc++-v3/include/Makefile.am.orig 2017-10-27 15:30:16.000000000 +1100 +++ gcc-7.2.0/libstdc++-v3/include/Makefile.am 2017-10-27 15:34:00.000000000 +1100 @@ -22,6 +22,8 @@ include $(top_srcdir)/fragment.am +LN_S = cp + # Standard C++ includes. std_srcdir = ${glibcxx_srcdir}/include/std std_builddir = . --- gcc-7.2.0/libstdc++-v3/include/Makefile.in.orig 2017-10-27 15:33:44.000000000 +1100 +++ gcc-7.2.0/libstdc++-v3/include/Makefile.in 2017-10-27 15:34:05.000000000 +1100 @@ -163,7 +163,7 @@ LIBS = @LIBS@ LIBTOOL = @LIBTOOL@ LIPO = @LIPO@ -LN_S = @LN_S@ +LN_S = cp LONG_DOUBLE_COMPAT_FLAGS = @LONG_DOUBLE_COMPAT_FLAGS@ LTLIBICONV = @LTLIBICONV@ LTLIBOBJS = @LTLIBOBJS@ In terms of make I would expect `cp` and `ln -s` to be the same. Maybe Apple would like to help out?
Thanks, Chris. It seems like APFS probably has a bug where the dentries for symlinks are not flushed to disk, and so later attempts to open the file fail.
Misty De Meo, I see you filed a RADAR where Apple said it wasn't their problem, and then they suggested you follow up with Apple DTS. Did you do that, and if so did you discover anything new?
The consensus of this thread is that APFS has a bug that HFS+ does not. I also remember that last autumn I was able to build gcc-7.2.0 from source on Sierra. Two weeks later, after upgrading to High Sierra, the same build failed. I just compiled gcc-7.3.0 on 10.13.3 using fink's build mechanism and a large empty non-encrypted HFS+ formatted image file that I created with Disk Utility, and then attached (mounted) at the root of the directory tree where gcc will be unpacked and the "objdir" resides. In fink's case that means mounting the HFS+ image as /sw/fink/src/fink.build after stashing the original "fink.build" to the side. The build utilized all 8 HT cores of the i7, and successfully compiled and installed gcc-7.3.0 (gcc, g++, gfortran) on my machine. I have not tried to compile gcc from source, without fink, using the HFS+ image file work-around, though I don't see why it should not work.
I can confirm that the latest gcc 8 snapshot still fails by default, but it works with 8 cores using Chris's fix above of replacing ln -s with cp. This in my mind pretty conclusively points to it not being a makefile logic error, but rather a filesystem error. However, regardless of whose fault it is, Chris's patch represents an actual viable solution to the problem, and is simple to understand, and does not unduly penalize other platforms. This situation has persisted for far too long and it makes GCC look bad and lose actual users, regardless of whether Apple or GCC caused the problem.
I raised an Apple bug report last December, the number is 36163995. Nothing useful has happened. I will ping the bug and ask what is happening.
The patch in comment 45 is not acceptable for all platforms. I'll entertain a patch that only affects the broken platforms, but not something that will end up being carried around forever and for platforms with working filesystems.
Jonathan, Would the patch in comment 42 be acceptable? I'm suggesting it as an interim fix, limited to the known affected build triplets while get somehow get Apple to fix the APFS issue, so that GCC builds out of the box for macOS users. I confirm that it fixes the problem on darwin. Index: configure.ac =================================================================== --- configure.ac (revision 257657) +++ configure.ac (working copy) @@ -473,6 +473,12 @@ AM_CONDITIONAL(BUILD_PDF, test $ac_cv_prog_DBLATEX = "yes" && test $ac_cv_prog_PDFLATEX = "yes") +case "$build" in + *-*-darwin* ) glibcxx_include_dir_notparallel=yes ;; + * ) glibcxx_include_dir_notparallel=no ;; +esac +AM_CONDITIONAL(INCLUDE_DIR_NOTPARALLEL, + test $glibcxx_include_dir_notparallel = "yes") # Propagate the target-specific source directories through the build chain. ATOMICITY_SRCDIR=config/${atomicity_dir} Index: include/Makefile.am =================================================================== --- include/Makefile.am (revision 257657) +++ include/Makefile.am (working copy) @@ -1479,3 +1479,7 @@ $(decimal_headers): ; @: $(ext_headers): ; @: $(experimental_headers): ; @: $(experimental_bits_headers): ; @: +if INCLUDE_DIR_NOTPARALLEL +# See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 +.NOTPARALLEL: +endif
Yes limiting it to darwin is OK, I'll make that change.
Thanks! Given that it affects bootstrap, maybe I ask that it be included in all active branches?
Would it be worthwhile to limit it to "darwin" *and* "apfs" on objdir? I am thinking of something along the lines of diskutil info $(stat -f '%Sd' /path/to/objdir) | \ perl -lane 'print $F[$#F] if /^\s+type/i' Once the build system determined "darwin", "diskutil" and "stat" should be readily available. The expression above returns "apfs" if you need to enact the patch, and "hfs" if you do not.
(In reply to Jens-S. Vöckler from comment #55) > Would it be worthwhile to limit it to "darwin" *and* "apfs" on objdir? There is very little downside to applying on all darwin systems (negligible increase in build time). I would advise to keep it simple.
(In reply to Francois-Xavier Coudert from comment #56) > I would advise to keep it simple. Agreed: Simple is better.
Author: redi Date: Thu Feb 15 20:56:41 2018 New Revision: 257710 URL: https://gcc.gnu.org/viewcvs?rev=257710&root=gcc&view=rev Log: PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin PR libstdc++/81797 * configure.ac (INCLUDE_DIR_NOTPARALLEL): Define. * configure: Regenerate. * include/Makefile.am (INCLUDE_DIR_NOTPARALLEL): Add .NOTPARALLEL when defined. * include/Makefile.in: Regenerate. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/configure trunk/libstdc++-v3/configure.ac trunk/libstdc++-v3/include/Makefile.am trunk/libstdc++-v3/include/Makefile.in
Should be fixed on trunk, please test and confirm.
(In reply to Jonathan Wakely from comment #59) > Should be fixed on trunk, please test and confirm. Confirmed fixed on trunk. Many thanks. Could you please backport to gcc-7-branch and gcc-6-branch? Or okay the backport, which I would be happy to apply.
Author: redi Date: Mon Feb 19 16:02:38 2018 New Revision: 257808 URL: https://gcc.gnu.org/viewcvs?rev=257808&root=gcc&view=rev Log: PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin Backport from mainline 2018-02-15 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/81797 * configure.ac (INCLUDE_DIR_NOTPARALLEL): Define. * configure: Regenerate. * include/Makefile.am (INCLUDE_DIR_NOTPARALLEL): Add .NOTPARALLEL when defined. * include/Makefile.in: Regenerate. Modified: branches/gcc-7-branch/libstdc++-v3/ChangeLog branches/gcc-7-branch/libstdc++-v3/configure branches/gcc-7-branch/libstdc++-v3/configure.ac branches/gcc-7-branch/libstdc++-v3/include/Makefile.am branches/gcc-7-branch/libstdc++-v3/include/Makefile.in
Author: redi Date: Mon Feb 19 17:02:38 2018 New Revision: 257811 URL: https://gcc.gnu.org/viewcvs?rev=257811&root=gcc&view=rev Log: PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin Backport from mainline 2018-02-15 Jonathan Wakely <jwakely@redhat.com> PR libstdc++/81797 * configure.ac (INCLUDE_DIR_NOTPARALLEL): Define. * configure: Regenerate. * include/Makefile.am (INCLUDE_DIR_NOTPARALLEL): Add .NOTPARALLEL when defined. * include/Makefile.in: Regenerate. Modified: branches/gcc-6-branch/libstdc++-v3/ChangeLog branches/gcc-6-branch/libstdc++-v3/configure branches/gcc-6-branch/libstdc++-v3/configure.ac branches/gcc-6-branch/libstdc++-v3/include/Makefile.am branches/gcc-6-branch/libstdc++-v3/include/Makefile.in
Workaround in place for 6.4, 7.4 and 8.1 For older releases don't build libstdc++ with -j or hack the sources (at least until APFS gets fixed).
(In reply to Jonathan Wakely from comment #63) > Workaround in place for 6.4, 7.4 and 8.1 Oops, 6.5 not 6.4
I am still seeing this issue with the patch https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00933.html applied to gcc-7.3.0 (RTEMS 5 [master]) tool builds. This is on Mojave and an fully updated Xcode. The ARM tools built but the SPARC tools do not and it currently seem repeatable. This is on a 2.6GHz i7 with an internal 1T SSD.
Yes, I was afraid the RTEMS failures might be a different problem. Are the symptoms the same? i.e. missing C++ standard library headers? Comment 17 suggests you're seeing missing libgcc headers, which is created by a different makefile. Maybe a similar kluge is needed in libgcc/Makefile for build=*darwin* What are your build, host and target triplets?
(In reply to Jonathan Wakely from comment #66) > Yes, I was afraid the RTEMS failures might be a different problem. > > Are the symptoms the same? i.e. missing C++ standard library headers? > Yes it seems to be the same issue I was seeing when we first looked into the problem. > Comment 17 suggests you're seeing missing libgcc headers, which is created > by a different makefile. Maybe a similar kluge is needed in libgcc/Makefile > for build=*darwin* Is it? I think that file is being installed in the same way. Could it be the RTEMS target config has a different list? > What are your build, host and target triplets? They are: --build=x86_64-apple-darwin18.0.0 --target=sparc-rtems5 --host=x86_64-apple-darwin18.0.0 The configure command line is ... ../gcc-7.3.0/configure --prefix=/Users/chris/development/rtems/5 --bindir=/Users/chris/development/rtems/5/bin --exec_prefix=/Users/chris/development/rtems/5 --includedir=/Users/chris/development/rtems/5/include --libdir=/Users/chris/development/rtems/5/lib --libexecdir=/Users/chris/development/rt ems/5/libexec --mandir=/Users/chris/development/rtems/5/share/man --infodir=/Users/chris/development/rtems/5/share/info --datadir=/Users/chris/development/rtems/5/share --build=x86_64-apple-darwin18.0.0 --host=x86_64-apple-darwin18.0.0 --target=sparc-rtems5 --disable-libstdcxx-pch --with-gnu-as --with-gnu-ld --verbose --with-newlib --disable-nls --without-included-gettext --disable-win32-registry --enable-version-specific-runtime-libs --disable-lto --enable-newlib-io-c99-formats --enable-newlib-iconv --enable-newlib-iconv-encodings=big5,cp775,cp850,cp852,cp855,cp866,euc_jp,euc_kr,euc_tw,iso_88 59_1,iso_8859_10,iso_8859_11,iso_8859_13,iso_8859_14,iso_8859_15,iso_8859_2,iso_8859_3,iso_8859_4,iso_8859_5,iso_8859_6,iso_8859_7,iso_8859_8,iso_8859_9,iso_ir_111,koi8_r,koi8_ru,koi8_u,koi8_uni,ucs_2,ucs_2_internal,ucs_2be,ucs_2le,ucs_4,ucs_4_internal,ucs_4be,ucs_4le,us_ascii,utf_16,utf_16be,utf_16 le,utf_8,win_1250,win_1251,win_1252,win_1253,win_1254,win_1255,win_1256,win_1257,win_1258 --enable-threads --disable-plugin --enable-libgomp --enable-languages=c,c++
(In reply to Chris Johns from comment #67) > (In reply to Jonathan Wakely from comment #66) > > Yes, I was afraid the RTEMS failures might be a different problem. > > > > Are the symptoms the same? i.e. missing C++ standard library headers? > > > > Yes it seems to be the same issue I was seeing when we first looked into the > problem. So not failing on "bits/gthr.h" then? I'm still not clear exactly what part fails for you now. > > Comment 17 suggests you're seeing missing libgcc headers, which is created > > by a different makefile. Maybe a similar kluge is needed in libgcc/Makefile > > for build=*darwin* > > Is it? I think that file is being installed in the same way. Could it be the > RTEMS target config has a different list? Ah yes, my mistake, libstdc++ creates $target/include/x86_64-pc-linux-gnu/bits/gthr.h I thought we found that in $target/libgcc/ instead, but in fact we process the libgcc/gthr.h header using sed and create our own version. That means it's definitely *not* the same way as the other headers, because the others are symlinks into the source tree. Please clarify exactly what your current failure is.
(In reply to Jonathan Wakely from comment #68) > (In reply to Chris Johns from comment #67) > > (In reply to Jonathan Wakely from comment #66) > > > Yes, I was afraid the RTEMS failures might be a different problem. > > > > > > Are the symptoms the same? i.e. missing C++ standard library headers? > > > > > > > Yes it seems to be the same issue I was seeing when we first looked into the > > problem. > > So not failing on "bits/gthr.h" then? I'm still not clear exactly what part > fails for you now. > > > > Comment 17 suggests you're seeing missing libgcc headers, which is created > > > by a different makefile. Maybe a similar kluge is needed in libgcc/Makefile > > > for build=*darwin* > > > > Is it? I think that file is being installed in the same way. Could it be the > > RTEMS target config has a different list? > > Ah yes, my mistake, libstdc++ creates > $target/include/x86_64-pc-linux-gnu/bits/gthr.h > > I thought we found that in $target/libgcc/ instead, but in fact we process > the libgcc/gthr.h header using sed and create our own version. > > That means it's definitely *not* the same way as the other headers, because > the others are symlinks into the source tree. > > Please clarify exactly what your current failure is. This is the current failure, it varies on the file that it fails on: In file included from /Users/chris/development/rtems/rsb/rtems-source-builder.git/rtems/build/sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-apple-darwin18.0.0-1/gcc-7.3.0/libstdc++-v3/libsupc++/exception:143:0, from ../../../../gcc-7.3.0/libstdc++-v3/libsupc++/new:40, from ../../../../gcc-7.3.0/libstdc++-v3/libsupc++/bad_alloc.cc:26: /Users/chris/development/rtems/rsb/rtems-source-builder.git/rtems/build/sparc-rtems5-gcc-7.3.0-newlib-d13c84eb07e35984bf7a974cd786a6cdac29e6b9-x86_64-apple-darwin18.0.0-1/build/sparc-rtems5/libstdc++-v3/include/bits/nested_exception.h:40:10: fatal error: bits/move.h: No such file or directory #include <bits/move.h> ^~~~~~~~~~~~~
Drat, that is one of the symlinked files.
I can also confirm this bug is still present: MacOS High Sierra, building gcc 9.1.0 with GNU Make 3.81 Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-first/./gcc/xgcc -B/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-first/./gcc/ -B/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/x86_64-apple-darwin18.6.0/bin/ -B/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/x86_64-apple-darwin18.6.0/lib/ -isystem /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/x86_64-apple-darwin18.6.0/include -isystem /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/x86_64-apple-darwin18.6.0/sys-include -fno-checking -g -O2 -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/host/include -L/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/host/lib -w -m32 -O2 -g -O2 -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/host/include -L/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/package/743cf0321be3152777da4d05247a66d1552e70a2/host/lib -w -DIN_GCC -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wno-format -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -isystem ./include -mmacosx-version-min=10.5 -pipe -fno-common -g -DIN_LIBGCC2 -fbuilding-libgcc -fno-stack-protector -Dinhibit_libc -mmacosx-version-min=10.5 -pipe -fno-common -I. -I. -I../../.././gcc -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libgcc -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libgcc/. -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libgcc/../gcc -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libgcc/../include -o enable-execute-stack.o -MT enable-execute-stack.o -MD -MP -MF enable-execute-stack.dep -c enable-execute-stack.c -fvisibility=hidden -DHIDE_EXPORTS enable-execute-stack.c:25:10: fatal error: sys/mman.h: No such file or directory
(In reply to Damien Merenne from comment #71) > enable-execute-stack.c:25:10: fatal error: sys/mman.h: No such file or > directory That's a completely different error. That header is not part of GCC.
I agree with Damien Merenne: I recently tried to build gcc 8 on High Sierra on an APFS in various ways, and it failed every time. I used my old work-around of creating an HFS+ partition-in-a-file to build gcc 8 within, and it did build fine. This tells me that the symptoms described in this bug are still present in recent sources.
Oh yeah, I forgot to mention it is building with -j1
Indeed in my previous comment the bug seemed to be something else, but I just reproduced the original bug: In file included from /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/new:40, from /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/bad_array_new.cc:24: /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/exception:144:10: fatal error: bits/nested_exception.h: No such file or directory 144 | #include <bits/nested_exception.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated. make[8]: *** [bad_array_new.lo] Error 1 make[8]: *** Waiting for unfinished jobs.... make[7]: *** [all-recursive] Error 1 make[6]: *** [all] Error 2 make[5]: *** [multi-do] Error 1 make[4]: *** [all-multi] Error 2 make[3]: *** [all-recursive] Error 1 make[2]: *** [all] Error 2 make[1]: *** [all-target-libstdc++-v3] Error 2 make: *** [all] Error 2 It's in libstdc++ and the header is from gcc.
And our best guess is still that Apple's new filesystem has a bug. Does it work if you use this? make LN_S="cp -pR" If that works, we can change the makefiles to copy files on darwin, instead of using symlinks.
I reproduced it twice, last time with: libtool: compile: /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-final/./gcc/xgcc -shared-libgcc -B/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-final/./gcc -nostdinc++ -L/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-final/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/src -L/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-final/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/src/.libs -L/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-final/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/libsupc++/.libs -B/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/package/743cf0321be3152777da4d05247a66d1552e70a2/arm-none-eabi/bin/ -B/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/package/743cf0321be3152777da4d05247a66d1552e70a2/arm-none-eabi/lib/ -isystem /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/package/743cf0321be3152777da4d05247a66d1552e70a2/arm-none-eabi/include -isystem /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/package/743cf0321be3152777da4d05247a66d1552e70a2/arm-none-eabi/sys-include -mthumb -march=armv6s-m -mfloat-abi=soft -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/../libgcc -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-final/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/include/arm-none-eabi -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-final/arm-none-eabi/thumb/v6-m/nofp/libstdc++-v3/include -I/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++ -fno-implicit-templates -Wall -Wextra -Wwrite-strings -Wcast-qual -Wabi=2 -fdiagnostics-show-location=once -ffunction-sections -fdata-sections -frandom-seed=bad_typeid.lo -g -O2 -mthumb -march=armv6s-m -mfloat-abi=soft -c /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/bad_typeid.cc -o bad_typeid.o In file included from /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/cxxabi.h:206, from /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/atexit_arm.cc:24: /Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/gcc-9.1.0/libstdc++-v3/libsupc++/typeinfo:36:10: fatal error: bits/hash_bytes.h: No such file or directory 36 | #include <bits/hash_bytes.h> | ^~~~~~~~~~~~~~~~~~~
And is that using LN_S="cp -pR" ? And -j1 ?
not -j1. Only the LN_S trick.
And the headers in $target/libstdc++-v3/include/bits are now regular files, not symlinks?
Basically we think there's a bug in the APFS filesystem, nobody can reproduce it on other systems, none of us have access to such a system. It would be really helpful if somebody seeing the error could investigate and tell us more than "it still fails for me".
I had some prior issues with w.r.t 32bits. Tinkering, this script does build a gcc 9.1 on macOS 10.14.5 on APFS. I didn't create it for beauty, and it's specific to my setup. The resulting compiler is unable to generate 32bit stuff. #!/bin/bash # here="$PWD" trap 'cd "$here"' EXIT prefix=/opt/gcc-9.1.0 if [[ ! -d $prefix ]]; then echo "FATAL: No such directory: $prefix" 1>&2 exit 1 fi # fix for fink interference PATH=$(echo $PATH | \ tr -d '\012' | \ tr ':' '\012' | \ fgrep -v /sw/bin | \ tr '\012' ':') export PATH="$PATH:/sw/bin"; echo "PATH=$PATH" set -v test -d gcc-9.1.0 || gtar xJf gcc-9.1.0.tar.xz cd gcc-9.1.0 test -d gmp-6.1.2 || gtar xJf ../gmp-6.1.2.tar.xz test -e gmp || ln -s gmp-6.1.2 gmp test -d mpfr-4.0.2 || gtar xJf ../mpfr-4.0.2.tar.xz test -e mpfr || ln -s mpfr-4.0.2 mpfr test -d mpc-1.1.0 || gtar xzf ../mpc-1.1.0.tar.gz test -e mpc || ln -s mpc-1.1.0 mpc test -d isl-0.18 || gtar xjf ../isl-0.18.tar.bz2 test -e isl || ln -s isl-0.18 isl mkdir objdir cd objdir set +v ../configure "--prefix=$prefix" \ --enable-languages=c,c++,fortran,lto,objc,obj-c++ \ --with-system-zlib \ --disable-multilib \ --with-cpu=core2 \ --enable-threads \ "--with-sysroot=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk" test $? -eq 0 || exit 2 make -j 3 BOOT_CFLAGS='-O' bootstrap test $? -eq 0 || exit 42 make install ---&< snip, snip &<--- $ file /opt/gcc-9.1.0/bin/g++ /opt/gcc-9.1.0/bin/g++: Mach-O 64-bit executable x86_64 $ /opt/gcc/bin/g++ hello.cc -o hello $ file hello hello: Mach-O 64-bit executable x86_64 $ otool -L hello hello: /opt/gcc-9.1.0/lib/libstdc++.6.dylib (compatibility version 7.0.0, current version 7.26.0) /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1252.250.1) /opt/gcc-9.1.0/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0) $ ./hello Hello, world