Bug 81797 - gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
Summary: gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 7.2.0
: P3 normal
Target Milestone: 6.5
Assignee: Jonathan Wakely
URL:
Keywords: build, patch
Depends on:
Blocks:
 
Reported: 2017-08-10 13:20 UTC by Francois-Xavier Coudert
Modified: 2018-11-02 00:55 UTC (History)
11 users (show)

See Also:
Host: x86_64-apple-darwin17.0.0
Target: x86_64-apple-darwin17.0.0
Build: x86_64-apple-darwin17.0.0
Known to work:
Known to fail:
Last reconfirmed: 2017-08-17 00:00:00


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Francois-Xavier Coudert 2017-08-10 13:20:59 UTC
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
Comment 1 Jonathan Wakely 2017-08-10 14:31:19 UTC
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.
Comment 2 Jonathan Wakely 2017-08-10 14:38:47 UTC
Do you have the file $target/libstdc++-v3/include/stamp-bits-sup ?
Comment 3 Misty De Meo 2017-08-16 16:56:35 UTC
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.
Comment 4 Eric Gallager 2017-08-17 16:00:51 UTC
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.
Comment 5 Francois-Xavier Coudert 2017-08-20 09:14:54 UTC
Same bug exists with GCC 7.2.0 and GCC 6.4.0, when compiled on a APFS filesystem.
Comment 6 Romain Bossart 2017-08-22 13:45:52 UTC
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
Comment 7 Jack Howarth 2017-08-23 22:57:15 UTC
(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.
Comment 8 Romain Bossart 2017-08-24 22:02:28 UTC
Hi Jack,

Thanks. My system is a Core i7 (HT enabled), so I have 8 cores, good catch!

Regards,
Romain
Comment 9 Misty De Meo 2017-08-25 16:56:11 UTC
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.
Comment 10 Jack Howarth 2017-08-26 22:30:48 UTC
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
Comment 11 Jack Howarth 2017-08-30 11:54:59 UTC
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.
Comment 12 Jack Howarth 2017-09-02 16:10:54 UTC
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.
Comment 13 Jack Howarth 2017-09-02 22:04:27 UTC
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>,
Comment 14 Romain Bossart 2017-09-03 12:13:54 UTC
Thank you Jack, gcc-7.2.0 now compiles correctly on my i7 system (8 cores HT) with encrypted APFS

Best regards
Comment 15 Jack Howarth 2017-09-03 13:00:14 UTC
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.
Comment 16 Jack Howarth 2017-09-03 13:16:15 UTC
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,
Comment 17 Chris Johns 2017-10-08 21:23:42 UTC
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.
Comment 18 Francois-Xavier Coudert 2017-10-08 21:46:04 UTC
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.
Comment 19 Chris Johns 2017-10-08 21:54:54 UTC
(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
Comment 20 Chris Johns 2017-10-11 14:38:07 UTC
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.
Comment 21 Campbell 2017-10-18 04:06:48 UTC
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.
Comment 22 Jonathan Wakely 2017-10-18 12:48:38 UTC
So maybe somebody should submit the patch to the mailing lists.
Comment 23 Francois-Xavier Coudert 2017-10-18 14:54:27 UTC
(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".
Comment 24 Chris Johns 2017-10-18 22:35:29 UTC
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.
Comment 25 Jack Howarth 2017-10-19 00:21:03 UTC
(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?
Comment 26 Jonathan Wakely 2017-10-19 00:30:30 UTC
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.
Comment 27 Chris Johns 2017-10-19 00:34:24 UTC
(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?
Comment 28 Marc Glisse 2017-10-19 05:38:32 UTC
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.
Comment 29 Francois-Xavier Coudert 2017-10-19 08:11:22 UTC
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
Comment 30 Marc Glisse 2017-10-19 13:08:46 UTC
(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 .
Comment 31 Misty De Meo 2017-10-19 16:37:05 UTC
> 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."
Comment 32 Marc Glisse 2017-10-19 18:28:18 UTC
(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 :-(
Comment 33 Jonathan Wakely 2017-10-25 11:18:08 UTC
(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.
Comment 34 Jonathan Wakely 2017-10-25 11:40:07 UTC
(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.
Comment 35 Jonathan Wakely 2017-10-25 11:57:12 UTC
(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?
Comment 36 Jonathan Wakely 2017-10-25 11:57:52 UTC
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).
Comment 37 Francois-Xavier Coudert 2017-10-25 13:31:23 UTC
(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
Comment 38 Chris Johns 2017-10-25 22:54:57 UTC
(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.
Comment 39 Jonathan Wakely 2017-10-25 23:14:48 UTC
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.
Comment 40 Campbell 2017-10-25 23:51:29 UTC
(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.
Comment 41 Misty De Meo 2017-10-26 00:02:02 UTC
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?
Comment 42 Jonathan Wakely 2017-10-26 11:30:41 UTC
(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
Comment 43 Jonathan Wakely 2017-10-26 11:31:38 UTC
(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.
Comment 44 Chris Johns 2017-10-27 03:08:24 UTC
(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
Comment 45 Chris Johns 2017-10-27 06:06:42 UTC
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?
Comment 46 Jonathan Wakely 2017-10-27 13:01:49 UTC
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.
Comment 47 Ryan Schmidt 2017-12-20 08:36:35 UTC
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?
Comment 48 Jens-S. Vöckler 2018-02-02 21:44:17 UTC
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.
Comment 49 Campbell 2018-02-02 22:03:35 UTC
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.
Comment 50 Chris Johns 2018-02-04 21:44:52 UTC
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.
Comment 51 Jonathan Wakely 2018-02-05 00:02:42 UTC
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.
Comment 52 Francois-Xavier Coudert 2018-02-15 10:28:19 UTC
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
Comment 53 Jonathan Wakely 2018-02-15 11:26:44 UTC
Yes limiting it to darwin is OK, I'll make that change.
Comment 54 Francois-Xavier Coudert 2018-02-15 12:54:27 UTC
Thanks! Given that it affects bootstrap, maybe I ask that it be included in all active branches?
Comment 55 Jens-S. Vöckler 2018-02-15 16:39:41 UTC
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.
Comment 56 Francois-Xavier Coudert 2018-02-15 16:41:16 UTC
(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.
Comment 57 Jens-S. Vöckler 2018-02-15 16:45:25 UTC
(In reply to Francois-Xavier Coudert from comment #56)
> I would advise to keep it simple.

Agreed: Simple is better.
Comment 58 Jonathan Wakely 2018-02-15 20:57:13 UTC
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
Comment 59 Jonathan Wakely 2018-02-15 21:16:27 UTC
Should be fixed on trunk, please test and confirm.
Comment 60 Francois-Xavier Coudert 2018-02-17 15:16:38 UTC
(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.
Comment 61 Jonathan Wakely 2018-02-19 16:03:10 UTC
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
Comment 62 Jonathan Wakely 2018-02-19 17:03:10 UTC
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
Comment 63 Jonathan Wakely 2018-02-19 17:04:14 UTC
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).
Comment 64 Jonathan Wakely 2018-02-23 20:59:38 UTC
(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
Comment 65 Chris Johns 2018-09-27 01:24:31 UTC
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.
Comment 66 Jonathan Wakely 2018-09-27 07:46:35 UTC
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?
Comment 67 Chris Johns 2018-09-27 08:20:36 UTC
(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++
Comment 68 Jonathan Wakely 2018-09-27 10:13:18 UTC
(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.
Comment 69 Chris Johns 2018-09-27 11:51:02 UTC
(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>
          ^~~~~~~~~~~~~
Comment 70 Jonathan Wakely 2018-09-27 12:03:19 UTC
Drat, that is one of the symlinked files.