[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[jens4303 at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #82 from Jens-S. Vöckler  ---
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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #81 from Jonathan Wakely  ---
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".

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #80 from Jonathan Wakely  ---
And the headers in $target/libstdc++-v3/include/bits are now regular files, not
symlinks?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[dam at cosinux dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #79 from Damien Merenne  ---
not -j1. Only the LN_S trick.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #78 from Jonathan Wakely  ---
And is that using LN_S="cp -pR" ? And -j1 ?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[dam at cosinux dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #77 from Damien Merenne  ---
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 
  |  ^~~

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #76 from Jonathan Wakely  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[dam at cosinux dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #75 from Damien Merenne  ---
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 
  |  ^
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[dam at cosinux dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #74 from Damien Merenne  ---
Oh yeah, I forgot to mention it is building with -j1

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[jens4303 at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #73 from Jens-S. Vöckler  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #72 from Jonathan Wakely  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[dam at cosinux dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Damien Merenne  changed:

   What|Removed |Added

 CC||dam at cosinux dot org

--- Comment #71 from Damien Merenne  ---
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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #70 from Jonathan Wakely  ---
Drat, that is one of the symlinked files.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #69 from Chris Johns  ---
(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 
  ^

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #68 from Jonathan Wakely  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #67 from Chris Johns  ---
(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++

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #66 from Jonathan Wakely  ---
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?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #65 from Chris Johns  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Jonathan Wakely  changed:

   What|Removed |Added

   Target Milestone|6.4 |6.5

--- Comment #64 from Jonathan Wakely  ---
(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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Jonathan Wakely  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED
   Target Milestone|--- |6.4

--- Comment #63 from Jonathan Wakely  ---
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).

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #62 from Jonathan Wakely  ---
Author: redi
Date: Mon Feb 19 17:02:38 2018
New Revision: 257811

URL: https://gcc.gnu.org/viewcvs?rev=257811=gcc=rev
Log:
PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin

Backport from mainline
2018-02-15  Jonathan Wakely  

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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #61 from Jonathan Wakely  ---
Author: redi
Date: Mon Feb 19 16:02:38 2018
New Revision: 257808

URL: https://gcc.gnu.org/viewcvs?rev=257808=gcc=rev
Log:
PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin

Backport from mainline
2018-02-15  Jonathan Wakely  

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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #60 from Francois-Xavier Coudert  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #59 from Jonathan Wakely  ---
Should be fixed on trunk, please test and confirm.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #58 from Jonathan Wakely  ---
Author: redi
Date: Thu Feb 15 20:56:41 2018
New Revision: 257710

URL: https://gcc.gnu.org/viewcvs?rev=257710=gcc=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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[jens4303 at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #57 from Jens-S. Vöckler  ---
(In reply to Francois-Xavier Coudert from comment #56)
> I would advise to keep it simple.

Agreed: Simple is better.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #56 from Francois-Xavier Coudert  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[jens4303 at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #55 from Jens-S. Vöckler  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #54 from Francois-Xavier Coudert  ---
Thanks! Given that it affects bootstrap, maybe I ask that it be included in all
active branches?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Jonathan Wakely  changed:

   What|Removed |Added

 Status|NEW |ASSIGNED
   Assignee|unassigned at gcc dot gnu.org  |redi at gcc dot gnu.org

--- Comment #53 from Jonathan Wakely  ---
Yes limiting it to darwin is OK, I'll make that change.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #52 from Francois-Xavier Coudert  ---
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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #51 from Jonathan Wakely  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #50 from Chris Johns  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[rlcamp.pdx at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #49 from Campbell  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[jens4303 at me dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Jens-S. Vöckler  changed:

   What|Removed |Added

 CC||jens4303 at me dot com

--- Comment #48 from Jens-S. Vöckler  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[gcc at ryandesign dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Ryan Schmidt  changed:

   What|Removed |Added

 CC||gcc at ryandesign dot com

--- Comment #47 from Ryan Schmidt  ---
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?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #46 from Jonathan Wakely  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #45 from Chris Johns  ---
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.0 +1100
+++ gcc-7.2.0/libstdc++-v3/include/Makefile.am  2017-10-27 15:34:00.0
+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.0 +1100
+++ gcc-7.2.0/libstdc++-v3/include/Makefile.in  2017-10-27 15:34:05.0
+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?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #44 from Chris Johns  ---
(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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #43 from Jonathan Wakely  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #42 from Jonathan Wakely  ---
(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 
  ^~~
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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[misty at brew dot sh]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #41 from Misty De Meo  ---
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?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[rlcamp.pdx at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #40 from Campbell  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #39 from Jonathan Wakely  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #38 from Chris Johns  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #37 from Francois-Xavier Coudert  ---
(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 
  ^~
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  admin64B 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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #36 from Jonathan Wakely  ---
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).

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #35 from Jonathan Wakely  ---
(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 
>   ^
> 
> I can confirm that $target/libstdc++-v3/include/ios exists.

and:

--- Comment #7 from Francois-Xavier Coudert  ---
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 
  ^~
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?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #34 from Jonathan Wakely  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #33 from Jonathan Wakely  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #32 from Marc Glisse  ---
(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 :-(

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[misty at brew dot sh]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #31 from Misty De Meo  ---
> 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."

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #30 from Marc Glisse  ---
(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 .

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #29 from Francois-Xavier Coudert  ---
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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[glisse at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #28 from Marc Glisse  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #27 from Chris Johns  ---
(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?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #26 from Jonathan Wakely  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #25 from Jack Howarth  ---
(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?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #24 from Chris Johns  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #23 from Francois-Xavier Coudert  ---
(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".

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #22 from Jonathan Wakely  ---
So maybe somebody should submit the patch to the mailing lists.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[rlcamp.pdx at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Campbell  changed:

   What|Removed |Added

 CC||rlcamp.pdx at gmail dot com

--- Comment #21 from Campbell  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #20 from Chris Johns  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[chrisj at rtems dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #19 from Chris Johns  ---
(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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Francois-Xavier Coudert  changed:

   What|Removed |Added

  Component|target  |libstdc++

--- Comment #18 from Francois-Xavier Coudert  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[misty at brew dot sh]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Misty De Meo  changed:

   What|Removed |Added

 CC||misty at brew dot sh

--- Comment #3 from Misty De Meo  ---
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 
  ^

I can confirm that $target/libstdc++-v3/include/ios exists.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #13 from Jack Howarth  ---
(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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #12 from Francois-Xavier Coudert  ---
(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.”

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #11 from Jack Howarth  ---
(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).

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #10 from Francois-Xavier Coudert  ---
(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+).

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #9 from Jack Howarth  ---
(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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #8 from Francois-Xavier Coudert  ---
Can reproduce with GNU Make 4.2.1, on the same system.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #7 from Francois-Xavier Coudert  ---
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 
  ^~
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #6 from Francois-Xavier Coudert  ---
(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.)

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #5 from Francois-Xavier Coudert  ---
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=500 --split-size=500
--split-size=500 " "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 
  ^~
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/
Makefilecomplex experimental   
numeric stamp-debug
string
algorithm   complex.h   ext
optionalstamp-decimal  
string_view
any condition_variable  fenv.h  

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[fxcoudert at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Francois-Xavier Coudert  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2017-08-13
 Ever confirmed|0   |1

--- Comment #4 from Francois-Xavier Coudert  ---
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.

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[howarth.at.gcc at gmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

Jack Howarth  changed:

   What|Removed |Added

 CC||howarth.at.gcc at gmail dot com

--- Comment #3 from Jack Howarth  ---
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

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #2 from Jonathan Wakely  ---
Do you have the file $target/libstdc++-v3/include/stamp-bits-sup ?

[Bug libstdc++/81797] gcc 7.1.0 fails to build on macOS 10.13 (High Sierra):

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797

--- Comment #1 from Jonathan Wakely  ---
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.