https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #34 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(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.
