This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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


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

--- Comment #42 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]