https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Eric Gallager <egallager at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target| |x86_64-apple-darwin17.0.0
Status|UNCONFIRMED |NEW
Keywords| |build
Last reconfirmed| |2017-08-17
Component|libstdc++ |target
CC| |egallager at gcc dot gnu.org,
| |howarth.at.gcc at gmail dot com
Host| |x86_64-apple-darwin17.0.0
Ever confirmed|0 |1
Build| |x86_64-apple-darwin17.0.0
--- Comment #4 from Eric Gallager <egallager at gcc dot gnu.org> ---
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.
