public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
* [libstdc++, patch] Fix build on APFS file system
@ 2017-10-18 15:08 FX
  2017-10-18 20:59 ` Petr Ovtchenkov
                   ` (3 more replies)
  0 siblings, 4 replies; 20+ messages in thread
From: FX @ 2017-10-18 15:08 UTC (permalink / raw)
  To: gcc patches, libstdc++

[-- Attachment #1: Type: text/plain, Size: 654 bytes --]

Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60% from my own builds and results reported by others): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
This is reproducible with several versions of GNU make.

Changing libstdc++’s makefile to mark install-headers with .NOTPARALLEL fixes the issue. We've carried that patch in Homebrew (https://brew.sh) for a few months now, and have had no report of build issues since then.

Bootstrapped and regtested on x86_64-apple-darwin17 (as well as other platforms). OK to commit?

FX



[-- Attachment #2: parallel.ChangeLog --]
[-- Type: application/octet-stream, Size: 138 bytes --]

2017-10-18  Francois-Xavier Coudert  <fxcoudert@gcc.gnu.org>

	PR libstdc++/81797
	* include/Makefile.in: Unparallelize install-headers.


[-- Attachment #3: parallel.diff --]
[-- Type: application/octet-stream, Size: 668 bytes --]

Index: libstdc++-v3/include/Makefile.in
===================================================================
--- libstdc++-v3/include/Makefile.in	(revision 253855)
+++ libstdc++-v3/include/Makefile.in	(working copy)
@@ -1763,6 +1763,8 @@ ${pch3_output}: ${pch3_source} ${pch2_ou
 @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>,

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-18 15:08 [libstdc++, patch] Fix build on APFS file system FX
@ 2017-10-18 20:59 ` Petr Ovtchenkov
  2017-10-18 21:05   ` FX
  2017-10-18 21:17 ` Jonathan Wakely
                   ` (2 subsequent siblings)
  3 siblings, 1 reply; 20+ messages in thread
From: Petr Ovtchenkov @ 2017-10-18 20:59 UTC (permalink / raw)
  To: FX; +Cc: gcc patches, libstdc++

On Wed, 18 Oct 2017 16:51:37 +0200
FX <fxcoudert@gmail.com> wrote:

> Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail
> (failure rate for “make -j2” to “make -j8” is about 60% from my own builds and results reported
> by others): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 This is reproducible with several
> versions of GNU make.
> 
> Changing libstdc++’s makefile to mark install-headers with .NOTPARALLEL fixes the issue. We've
> carried that patch in Homebrew (https://brew.sh) for a few months now, and have had no report of
> build issues since then.
> 
> Bootstrapped and regtested on x86_64-apple-darwin17 (as well as other platforms). OK to commit?
> 
> FX
> 
> 

From supplied info not follow that problem is on gcc build side.
I can suspect that APFS has problem with direntry intensive
modification, for example.

--

  - ptr

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-18 20:59 ` Petr Ovtchenkov
@ 2017-10-18 21:05   ` FX
  0 siblings, 0 replies; 20+ messages in thread
From: FX @ 2017-10-18 21:05 UTC (permalink / raw)
  To: Petr Ovtchenkov; +Cc: gcc patches, libstdc++

> From supplied info not follow that problem is on gcc build side.
> I can suspect that APFS has problem with direntry intensive
> modification, for example.

As part of Homebrew, we have built 4000+ open source codes on this new filesystem, with parallel compilation. Some of them pretty intensive (clang, llvm, rust, ghc, and a ton of compilers, libraries, databases, etc.). Many of them several times (for testing, etc.). Macports has done the same, probably other projects as well.

We have not seen any evidence of a generic issue related to this filesystem. Apple is not aware of such an issue either, apparently. Yet, libstdc++ parallel builds have a very high failure rate. Other GCC libraries build fine, too.

I do not know how to debug parallel makefiles, otherwise I would do it. I have asked help on the GNU Make mailing-list (http://lists.gnu.org/archive/html/bug-make/2017-08/msg00034.html), but didn’t get any. So I cannot prove it (and fix it), but there is overwhelming evidence that the problem is in libstdc++.

FX

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-18 15:08 [libstdc++, patch] Fix build on APFS file system FX
  2017-10-18 20:59 ` Petr Ovtchenkov
@ 2017-10-18 21:17 ` Jonathan Wakely
  2017-10-18 22:22   ` FX
  2017-10-19  0:28   ` Jonathan Wakely
  2017-10-18 23:20 ` Hans-Peter Nilsson
  2017-10-23 17:44 ` Mike Stump
  3 siblings, 2 replies; 20+ messages in thread
From: Jonathan Wakely @ 2017-10-18 21:17 UTC (permalink / raw)
  To: FX; +Cc: gcc patches, libstdc++

On 18/10/17 16:51 +0200, FX wrote:
>Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60% from my own builds and results reported by others): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
>This is reproducible with several versions of GNU make.
>
>Changing libstdc++’s makefile to mark install-headers with .NOTPARALLEL fixes the issue. We've carried that patch in Homebrew (https://brew.sh) for a few months now, and have had no report of build issues since then.
>
>Bootstrapped and regtested on x86_64-apple-darwin17 (as well as other platforms). OK to commit?

Could you test using .PHONY: install-headers instead?

That target *is* phony, so telling make that seems sensible.

Presumably the same change is needed for install-freestanding-headers,
since it's very similar.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-18 21:17 ` Jonathan Wakely
@ 2017-10-18 22:22   ` FX
  2017-10-19  8:43     ` Richard Biener
  2017-10-19  0:28   ` Jonathan Wakely
  1 sibling, 1 reply; 20+ messages in thread
From: FX @ 2017-10-18 22:22 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: gcc patches, libstdc++

> Could you test using .PHONY: install-headers instead?
> That target *is* phony, so telling make that seems sensible.

I’ve tried adding it to the existing .PHONY list:

Index: libstdc++-v3/include/Makefile.in
===================================================================
--- libstdc++-v3/include/Makefile.in	(revision 253855)
+++ libstdc++-v3/include/Makefile.in	(working copy)
@@ -1449,6 +1449,7 @@ uninstall-am:
 	distclean-libtool dvi dvi-am html html-am info info-am install \
 	install-am install-data install-data-am install-data-local \
 	install-dvi install-dvi-am install-exec install-exec-am \
+	install-freestanding-headers install-headers \
 	install-html install-html-am install-info install-info-am \
 	install-man install-pdf install-pdf-am install-ps \
 	install-ps-am install-strip installcheck installcheck-am \


But that doesn’t work:

In file included from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/bits/exception_ptr.h:39:0,
                 from /Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++/exception:143,
                 from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/ios:39,
                 from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/istream:38,
                 from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/sstream:38,
                 from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/complex:45,
                 from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/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++/typeinfo:36:10: fatal error: bits/hash_bytes.h: No such file or directory
 #include <bits/hash_bytes.h>
          ^~~~~~~~~~~~~~~~~~~

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-18 15:08 [libstdc++, patch] Fix build on APFS file system FX
  2017-10-18 20:59 ` Petr Ovtchenkov
  2017-10-18 21:17 ` Jonathan Wakely
@ 2017-10-18 23:20 ` Hans-Peter Nilsson
  2017-10-19  1:11   ` Jonathan Wakely
  2017-10-23 17:44 ` Mike Stump
  3 siblings, 1 reply; 20+ messages in thread
From: Hans-Peter Nilsson @ 2017-10-18 23:20 UTC (permalink / raw)
  To: FX; +Cc: gcc patches, libstdc++

On Wed, 18 Oct 2017, FX wrote:

> Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for ?make -j2? to ?make -j8? is about 60% from my own builds and results reported by others): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
> This is reproducible with several versions of GNU make.
>
> Changing libstdc++?s makefile to mark install-headers with .NOTPARALLEL fixes the issue. We've carried that patch in Homebrew (https://brew.sh) for a few months now, and have had no report of build issues since then.
>
> Bootstrapped and regtested on x86_64-apple-darwin17 (as well as other platforms). OK to commit?

Maybe moot now, but .NOTPARALLEL doesn't work the way you imply
in the patch.  From TFM of GNU Make 3.81 and 4: "Any
prerequisites on this target are ignored."

To wit, it seems you'd get the effect, but for *every target* in
this Makefile.  (If I were you and the patch is still proposed,
I'd remove the unused target and add a comment on the intent.)

Assuming the documentation and my reading is correct.

brgds, H-P

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-18 21:17 ` Jonathan Wakely
  2017-10-18 22:22   ` FX
@ 2017-10-19  0:28   ` Jonathan Wakely
  1 sibling, 0 replies; 20+ messages in thread
From: Jonathan Wakely @ 2017-10-19  0:28 UTC (permalink / raw)
  To: FX; +Cc: gcc patches, libstdc++

On 18/10/17 22:05 +0100, Jonathan Wakely wrote:
>On 18/10/17 16:51 +0200, FX wrote:
>>Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60% from my own builds and results reported by others): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
>>This is reproducible with several versions of GNU make.
>>
>>Changing libstdc++’s makefile to mark install-headers with .NOTPARALLEL fixes the issue. We've carried that patch in Homebrew (https://brew.sh) for a few months now, and have had no report of build issues since then.
>>
>>Bootstrapped and regtested on x86_64-apple-darwin17 (as well as other platforms). OK to commit?
>
>Could you test using .PHONY: install-headers instead?
>
>That target *is* phony, so telling make that seems sensible.
>
>Presumably the same change is needed for install-freestanding-headers,
>since it's very similar.


.NOTPARALLEL ignores any prerequisites, so there's no point listing
install-headers as the prerequisite. Your patch disables parallelism
for all targets in the libstdc++-v3/install directory.

There must be another solution.


^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-18 23:20 ` Hans-Peter Nilsson
@ 2017-10-19  1:11   ` Jonathan Wakely
  0 siblings, 0 replies; 20+ messages in thread
From: Jonathan Wakely @ 2017-10-19  1:11 UTC (permalink / raw)
  To: Hans-Peter Nilsson; +Cc: FX, gcc patches, libstdc++

On 18/10/17 18:40 -0400, Hans-Peter Nilsson wrote:
>On Wed, 18 Oct 2017, FX wrote:
>
>> Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for ?make -j2? to ?make -j8? is about 60% from my own builds and results reported by others): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
>> This is reproducible with several versions of GNU make.
>>
>> Changing libstdc++?s makefile to mark install-headers with .NOTPARALLEL fixes the issue. We've carried that patch in Homebrew (https://brew.sh) for a few months now, and have had no report of build issues since then.
>>
>> Bootstrapped and regtested on x86_64-apple-darwin17 (as well as other platforms). OK to commit?
>
>Maybe moot now, but .NOTPARALLEL doesn't work the way you imply
>in the patch.  From TFM of GNU Make 3.81 and 4: "Any
>prerequisites on this target are ignored."
>
>To wit, it seems you'd get the effect, but for *every target* in
>this Makefile.  (If I were you and the patch is still proposed,
>I'd remove the unused target and add a comment on the intent.)
>
>Assuming the documentation and my reading is correct.

I think it is.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-18 22:22   ` FX
@ 2017-10-19  8:43     ` Richard Biener
  2017-10-19  8:49       ` FX
  2017-10-19 10:28       ` Petr Ovtchenkov
  0 siblings, 2 replies; 20+ messages in thread
From: Richard Biener @ 2017-10-19  8:43 UTC (permalink / raw)
  To: FX; +Cc: Jonathan Wakely, gcc patches, libstdc++

On Wed, Oct 18, 2017 at 11:58 PM, FX <fxcoudert@gmail.com> wrote:
>> Could you test using .PHONY: install-headers instead?
>> That target *is* phony, so telling make that seems sensible.
>
> I’ve tried adding it to the existing .PHONY list:
>
> Index: libstdc++-v3/include/Makefile.in
> ===================================================================
> --- libstdc++-v3/include/Makefile.in    (revision 253855)
> +++ libstdc++-v3/include/Makefile.in    (working copy)
> @@ -1449,6 +1449,7 @@ uninstall-am:
>         distclean-libtool dvi dvi-am html html-am info info-am install \
>         install-am install-data install-data-am install-data-local \
>         install-dvi install-dvi-am install-exec install-exec-am \
> +       install-freestanding-headers install-headers \
>         install-html install-html-am install-info install-info-am \
>         install-man install-pdf install-pdf-am install-ps \
>         install-ps-am install-strip installcheck installcheck-am \
>
>
> But that doesn’t work:
>
> In file included from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/bits/exception_ptr.h:39:0,
>                  from /Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++/exception:143,
>                  from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/ios:39,
>                  from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/istream:38,
>                  from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/sstream:38,
>                  from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/complex:45,
>                  from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/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++/typeinfo:36:10: fatal error: bits/hash_bytes.h: No such file or directory
>  #include <bits/hash_bytes.h>
>           ^~~~~~~~~~~~~~~~~~~

So the issue is PCH generation (why's that re-generated at install time?).

Richard.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-19  8:43     ` Richard Biener
@ 2017-10-19  8:49       ` FX
  2017-10-19 10:28       ` Petr Ovtchenkov
  1 sibling, 0 replies; 20+ messages in thread
From: FX @ 2017-10-19  8:49 UTC (permalink / raw)
  To: Richard Biener; +Cc: Jonathan Wakely, gcc patches, libstdc++

> So the issue is PCH generation (why's that re-generated at install time?).

As suggested by Marc in the PR, 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

FX

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-19  8:43     ` Richard Biener
  2017-10-19  8:49       ` FX
@ 2017-10-19 10:28       ` Petr Ovtchenkov
  1 sibling, 0 replies; 20+ messages in thread
From: Petr Ovtchenkov @ 2017-10-19 10:28 UTC (permalink / raw)
  To: Richard Biener; +Cc: FX, Jonathan Wakely, gcc patches, libstdc++

On Thu, 19 Oct 2017 10:37:14 +0200
Richard Biener <richard.guenther@gmail.com> wrote:

> On Wed, Oct 18, 2017 at 11:58 PM, FX <fxcoudert@gmail.com> wrote:
> >> Could you test using .PHONY: install-headers instead?
> >> That target *is* phony, so telling make that seems sensible.
> >
> > I’ve tried adding it to the existing .PHONY list:
> >
> > Index: libstdc++-v3/include/Makefile.in
> > ===================================================================
> > --- libstdc++-v3/include/Makefile.in    (revision 253855)
> > +++ libstdc++-v3/include/Makefile.in    (working copy)
> > @@ -1449,6 +1449,7 @@ uninstall-am:
> >         distclean-libtool dvi dvi-am html html-am info info-am install \
> >         install-am install-data install-data-am install-data-local \
> >         install-dvi install-dvi-am install-exec install-exec-am \
> > +       install-freestanding-headers install-headers \
> >         install-html install-html-am install-info install-info-am \
> >         install-man install-pdf install-pdf-am install-ps \
> >         install-ps-am install-strip installcheck installcheck-am \
> >
> >
> > But that doesn’t work:
> >
> > In file included
> > from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/bits/exception_ptr.h:39:0,
> > from /Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++/exception:143,
> > from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/ios:39,
> > from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/istream:38,
> > from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/sstream:38,
> > from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/complex:45,
> > from /Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/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++/typeinfo:36:10:
> > fatal error: bits/hash_bytes.h: No such file or directory #include <bits/hash_bytes.h>
> >           ^~~~~~~~~~~~~~~~~~~
> 
> So the issue is PCH generation (why's that re-generated at install time?).

May be indeed: I have a lot parallel builds and never see problem like this,
but I skip PCH generation.

--

   - ptr

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-18 15:08 [libstdc++, patch] Fix build on APFS file system FX
                   ` (2 preceding siblings ...)
  2017-10-18 23:20 ` Hans-Peter Nilsson
@ 2017-10-23 17:44 ` Mike Stump
  2017-10-23 17:55   ` FX
  3 siblings, 1 reply; 20+ messages in thread
From: Mike Stump @ 2017-10-23 17:44 UTC (permalink / raw)
  To: FX; +Cc: gcc patches, libstdc++

On Oct 18, 2017, at 7:51 AM, FX <fxcoudert@gmail.com> wrote:
> 
> Parallel builds of libstdc++ on APFS filesystem (with 1 ns granularity) on macOS 10.13 often fail (failure rate for “make -j2” to “make -j8” is about 60% from my own builds and results reported by others): https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
> This is reproducible with several versions of GNU make.
> 
> Changing libstdc++’s makefile to mark install-headers with .NOTPARALLEL fixes the issue. We've carried that patch in Homebrew (https://brew.sh) for a few months now, and have had no report of build issues since then.
> 
> Bootstrapped and regtested on x86_64-apple-darwin17 (as well as other platforms). OK to commit?

The patch seems like a rough bandaid to hide the real bug.  Better to identify the real bug.  If there is a missing dependency, then I'd like to think that adding the right dependency should resolve the issue.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-23 17:44 ` Mike Stump
@ 2017-10-23 17:55   ` FX
  2017-10-23 18:02     ` Jonathan Wakely
  0 siblings, 1 reply; 20+ messages in thread
From: FX @ 2017-10-23 17:55 UTC (permalink / raw)
  To: Mike Stump; +Cc: gcc patches, libstdc++

> The patch seems like a rough bandaid to hide the real bug.  Better to identify the real bug.  If there is a missing dependency, then I'd like to think that adding the right dependency should resolve the issue.

So far, apart from a suggestion from Marc, I haven’t received any help or advice in identifying or debugging the issue.

FX

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-23 17:55   ` FX
@ 2017-10-23 18:02     ` Jonathan Wakely
  2017-10-24  9:08       ` FX
  0 siblings, 1 reply; 20+ messages in thread
From: Jonathan Wakely @ 2017-10-23 18:02 UTC (permalink / raw)
  To: FX; +Cc: Mike Stump, gcc patches, libstdc++

[-- Attachment #1: Type: text/plain, Size: 405 bytes --]

On 23/10/17 19:48 +0200, FX wrote:
>> The patch seems like a rough bandaid to hide the real bug.  Better to identify the real bug.  If there is a missing dependency, then I'd like to think that adding the right dependency should resolve the issue.
>
>So far, apart from a suggestion from Marc, I haven’t received any help or advice in identifying or debugging the issue.
>
>FX

You could try this.



[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 1095 bytes --]

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 2c4d193d0a4..39083cc4ebc 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1016,6 +1016,8 @@ allcreated = \
 # Here are the rules for building the headers
 all-local: ${allstamped} ${allcreated}
 
+${pch_output} : | ${allstamped}
+
 # Ignore errors from 'mkdir -p' to avoid parallel make failure on
 # systems with broken mkdir.  Call mkdir unconditionally because
 # it is just as cheap to avoid going through the shell.
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index bc8556c68d2..e1a852e2906 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -1465,6 +1465,8 @@ uninstall-am:
 # Here are the rules for building the headers
 all-local: ${allstamped} ${allcreated}
 
+${pch_output} : | ${allstamped}
+
 # Ignore errors from 'mkdir -p' to avoid parallel make failure on
 # systems with broken mkdir.  Call mkdir unconditionally because
 # it is just as cheap to avoid going through the shell.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-23 18:02     ` Jonathan Wakely
@ 2017-10-24  9:08       ` FX
  2017-10-24 13:50         ` Jonathan Wakely
  0 siblings, 1 reply; 20+ messages in thread
From: FX @ 2017-10-24  9:08 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: Mike Stump, gcc patches, libstdc++

Thanks Jonathan. I tried, and it does not work, I still get the same error:

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
/Users/fx/devel/gcc/ibin/./gcc/xgcc -shared-libgcc -B/Users/fx/devel/gcc/ibin/./gcc -nostdinc++ -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src/.libs -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/libsupc++/.libs -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/bin/ -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/lib/ -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/include -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/sys-include  -m32 -x c++-header -nostdinc++ -g -O2  -m32  -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include -I/Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x /Users/fx/devel/gcc/trunk/libstdc++-v3/include/precompiled/stdc++.h \
	-o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch
/Users/fx/devel/gcc/ibin/./gcc/xgcc -shared-libgcc -B/Users/fx/devel/gcc/ibin/./gcc -nostdinc++ -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src/.libs -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/libsupc++/.libs -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/bin/ -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/lib/ -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/include -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/sys-include  -m32 -x c++-header -nostdinc++ -g -O2  -m32  -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include -I/Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++  -O2 -g /Users/fx/devel/gcc/trunk/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch
/Users/fx/devel/gcc/trunk/libstdc++-v3/include/precompiled/stdc++.h:44:10: fatal error: cstdarg: No such file or directory
 #include <cstdarg>
          ^~~~~~~~~
compilation terminated.
make[7]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-24  9:08       ` FX
@ 2017-10-24 13:50         ` Jonathan Wakely
  2017-10-24 14:19           ` FX
       [not found]           ` <1B1E8CBD-E34E-415A-A5D7-FB3AACA72749@gmail.com>
  0 siblings, 2 replies; 20+ messages in thread
From: Jonathan Wakely @ 2017-10-24 13:50 UTC (permalink / raw)
  To: FX; +Cc: Mike Stump, gcc patches, libstdc++

[-- Attachment #1: Type: text/plain, Size: 2635 bytes --]

On 24/10/17 11:06 +0200, FX wrote:
>Thanks Jonathan. I tried, and it does not work, I still get the same error:
>
>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
>/Users/fx/devel/gcc/ibin/./gcc/xgcc -shared-libgcc -B/Users/fx/devel/gcc/ibin/./gcc -nostdinc++ -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src/.libs -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/libsupc++/.libs -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/bin/ -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/lib/ -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/include -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/sys-include  -m32 -x c++-header -nostdinc++ -g -O2  -m32  -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include -I/Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++  -O2 -g -std=gnu++0x /Users/fx/devel/gcc/trunk/libstdc++-v3/include/precompiled/stdc++.h \
>	-o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch
>/Users/fx/devel/gcc/ibin/./gcc/xgcc -shared-libgcc -B/Users/fx/devel/gcc/ibin/./gcc -nostdinc++ -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/src/.libs -L/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/libsupc++/.libs -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/bin/ -B/Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/lib/ -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/include -isystem /Users/fx/devel/gcc/irun/x86_64-apple-darwin17.0.0/sys-include  -m32 -x c++-header -nostdinc++ -g -O2  -m32  -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include/x86_64-apple-darwin17.0.0 -I/Users/fx/devel/gcc/ibin/x86_64-apple-darwin17.0.0/i386/libstdc++-v3/include -I/Users/fx/devel/gcc/trunk/libstdc++-v3/libsupc++  -O2 -g /Users/fx/devel/gcc/trunk/libstdc++-v3/include/precompiled/stdc++.h -o x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2g.gch
>/Users/fx/devel/gcc/trunk/libstdc++-v3/include/precompiled/stdc++.h:44:10: fatal error: cstdarg: No such file or directory
> #include <cstdarg>
>          ^~~~~~~~~
>compilation terminated.
>make[7]: *** [x86_64-apple-darwin17.0.0/bits/stdc++.h.gch/O2ggnu++0x.gch] Error 1

OK, could you try this, and share the full output?



[-- Attachment #2: patch.txt --]
[-- Type: text/x-patch, Size: 7802 bytes --]

diff --git a/libstdc++-v3/include/Makefile.am b/libstdc++-v3/include/Makefile.am
index 2c4d193d0a4..92b9db80143 100644
--- a/libstdc++-v3/include/Makefile.am
+++ b/libstdc++-v3/include/Makefile.am
@@ -1022,43 +1022,43 @@ all-local: ${allstamped} ${allcreated}
 # Ignore errors from $(LN_S) because the links may already exist.
 stamp-std: ${std_headers}
 	@-mkdir -p ${std_builddir}
-	@-cd ${std_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${std_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-std
 
 stamp-bits: ${bits_headers}
 	@-mkdir -p ${bits_builddir}
-	@-cd ${bits_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${bits_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-bits
 
 stamp-bits-sup: stamp-bits ${bits_sup_headers}
-	@-cd ${bits_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${bits_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-bits-sup
 
 stamp-c_base: ${c_base_headers}
 	@-mkdir -p ${c_base_builddir}
-	@-cd ${c_base_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${c_base_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-c_base
 
 stamp-c_base_extra: ${c_base_headers_extra}
 	@-mkdir -p ${bits_builddir}
-	@-cd ${bits_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${bits_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-c_base_extra
 
 stamp-c_compatibility: ${c_compatibility_headers_extra}
 	@-mkdir -p ${c_compatibility_builddir}
-	@-if [ ! -z "${c_compatibility_headers_extra}" ]; then \
-	  cd ${c_compatibility_builddir} && $(LN_S) $? . 2>/dev/null ;\
+	-if [ ! -z "${c_compatibility_headers_extra}" ]; then \
+	  cd ${c_compatibility_builddir} && $(LN_S) $? . ;\
 	fi
 	@$(STAMP) stamp-c_compatibility
 
 stamp-backward: ${backward_headers}
 	@-mkdir -p ${backward_builddir}
-	@-cd ${backward_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${backward_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-backward
 
 stamp-ext: ${ext_headers}
 	@-mkdir -p ${ext_builddir}
-	@-cd ${ext_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${ext_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-ext
 
 # Have to deal with nested include directories, gah! Strip off source
@@ -1114,47 +1114,47 @@ stamp-pb:
 
 stamp-tr1: ${tr1_headers}
 	@-mkdir -p ${tr1_builddir}
-	@-cd ${tr1_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${tr1_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-tr1
 
 stamp-tr2: ${tr2_headers}
 	@-mkdir -p ${tr2_builddir}
-	@-cd ${tr2_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${tr2_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-tr2
 
 stamp-decimal: ${decimal_headers}
 	@-mkdir -p ${decimal_builddir}
-	@-cd ${decimal_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${decimal_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-decimal
 
 stamp-experimental: ${experimental_headers}
 	@-mkdir -p ${experimental_builddir}
-	@-cd ${experimental_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${experimental_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-experimental
 
 stamp-experimental-bits: ${experimental_bits_headers}
 	@-mkdir -p ${experimental_bits_builddir}
-	@-cd ${experimental_bits_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${experimental_bits_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-experimental-bits
 
 stamp-debug: ${debug_headers}
 	@-mkdir -p ${debug_builddir}
-	@-cd ${debug_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${debug_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-debug
 
 stamp-parallel: ${parallel_headers}
 	@-mkdir -p ${parallel_builddir}
-	@-cd ${parallel_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${parallel_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-parallel
 
 stamp-profile: ${profile_headers}
 	@-mkdir -p ${profile_builddir}
-	@-cd ${profile_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${profile_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-profile
 
 stamp-profile-impl: ${profile_impl_headers}
 	@-mkdir -p ${profile_impl_builddir}
-	@-cd ${profile_impl_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${profile_impl_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-profile-impl
 
 stamp-${host_alias}:
diff --git a/libstdc++-v3/include/Makefile.in b/libstdc++-v3/include/Makefile.in
index bc8556c68d2..69d7eca246e 100644
--- a/libstdc++-v3/include/Makefile.in
+++ b/libstdc++-v3/include/Makefile.in
@@ -1471,43 +1471,43 @@ all-local: ${allstamped} ${allcreated}
 # Ignore errors from $(LN_S) because the links may already exist.
 stamp-std: ${std_headers}
 	@-mkdir -p ${std_builddir}
-	@-cd ${std_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${std_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-std
 
 stamp-bits: ${bits_headers}
 	@-mkdir -p ${bits_builddir}
-	@-cd ${bits_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${bits_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-bits
 
 stamp-bits-sup: stamp-bits ${bits_sup_headers}
-	@-cd ${bits_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${bits_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-bits-sup
 
 stamp-c_base: ${c_base_headers}
 	@-mkdir -p ${c_base_builddir}
-	@-cd ${c_base_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${c_base_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-c_base
 
 stamp-c_base_extra: ${c_base_headers_extra}
 	@-mkdir -p ${bits_builddir}
-	@-cd ${bits_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${bits_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-c_base_extra
 
 stamp-c_compatibility: ${c_compatibility_headers_extra}
 	@-mkdir -p ${c_compatibility_builddir}
-	@-if [ ! -z "${c_compatibility_headers_extra}" ]; then \
-	  cd ${c_compatibility_builddir} && $(LN_S) $? . 2>/dev/null ;\
+	-if [ ! -z "${c_compatibility_headers_extra}" ]; then \
+	  cd ${c_compatibility_builddir} && $(LN_S) $? . ;\
 	fi
 	@$(STAMP) stamp-c_compatibility
 
 stamp-backward: ${backward_headers}
 	@-mkdir -p ${backward_builddir}
-	@-cd ${backward_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${backward_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-backward
 
 stamp-ext: ${ext_headers}
 	@-mkdir -p ${ext_builddir}
-	@-cd ${ext_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${ext_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-ext
 
 # Have to deal with nested include directories, gah! Strip off source
@@ -1563,47 +1563,47 @@ stamp-pb:
 
 stamp-tr1: ${tr1_headers}
 	@-mkdir -p ${tr1_builddir}
-	@-cd ${tr1_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${tr1_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-tr1
 
 stamp-tr2: ${tr2_headers}
 	@-mkdir -p ${tr2_builddir}
-	@-cd ${tr2_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${tr2_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-tr2
 
 stamp-decimal: ${decimal_headers}
 	@-mkdir -p ${decimal_builddir}
-	@-cd ${decimal_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${decimal_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-decimal
 
 stamp-experimental: ${experimental_headers}
 	@-mkdir -p ${experimental_builddir}
-	@-cd ${experimental_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${experimental_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-experimental
 
 stamp-experimental-bits: ${experimental_bits_headers}
 	@-mkdir -p ${experimental_bits_builddir}
-	@-cd ${experimental_bits_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${experimental_bits_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-experimental-bits
 
 stamp-debug: ${debug_headers}
 	@-mkdir -p ${debug_builddir}
-	@-cd ${debug_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${debug_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-debug
 
 stamp-parallel: ${parallel_headers}
 	@-mkdir -p ${parallel_builddir}
-	@-cd ${parallel_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${parallel_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-parallel
 
 stamp-profile: ${profile_headers}
 	@-mkdir -p ${profile_builddir}
-	@-cd ${profile_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${profile_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-profile
 
 stamp-profile-impl: ${profile_impl_headers}
 	@-mkdir -p ${profile_impl_builddir}
-	@-cd ${profile_impl_builddir} && $(LN_S) $? . 2>/dev/null
+	-cd ${profile_impl_builddir} && $(LN_S) $? .
 	@$(STAMP) stamp-profile-impl
 
 stamp-${host_alias}:

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-24 13:50         ` Jonathan Wakely
@ 2017-10-24 14:19           ` FX
       [not found]           ` <1B1E8CBD-E34E-415A-A5D7-FB3AACA72749@gmail.com>
  1 sibling, 0 replies; 20+ messages in thread
From: FX @ 2017-10-24 14:19 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: Mike Stump, gcc patches, libstdc++

The output of “make -j4” in a build at stage1, where I have just run "rm -rf x86_64-apple-darwin17.0.0/**/libstdc++-v3”, with the patch applied: https://gist.github.com/fxcoudert/46f0026c44eb3db2937ac0e92a477338

FX

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
       [not found]           ` <1B1E8CBD-E34E-415A-A5D7-FB3AACA72749@gmail.com>
@ 2017-10-24 15:06             ` Jonathan Wakely
  2017-10-24 15:22               ` FX
  0 siblings, 1 reply; 20+ messages in thread
From: Jonathan Wakely @ 2017-10-24 15:06 UTC (permalink / raw)
  To: FX; +Cc: Mike Stump, gcc patches, libstdc++

On 24/10/17 16:03 +0200, FX wrote:
>> OK, could you try this, and share the full output?
>
>Attached is the output of “make -j4” in a build at stage1, where I have just run "rm -rf x86_64-apple-darwin17.0.0/**/libstdc++-v3”, with the patch applied.
>
>FX

There are two commands that create the include/ext/new_allocator.h
symlink:

>cd ./ext && ln -s /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/algorithm /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/aligned_buffer.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/alloc_traits.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/atomicity.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/array_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/bitmap_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/cast.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/cmath /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/codecvt_specializations.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/concurrence.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/debug_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/enc_filebuf.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/extptr_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/stdio_filebuf.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/stdio_sync_filebuf.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/functional /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/iterator /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/malloc_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/memory /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/mt_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/new_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/numeric /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/numeric_traits.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/pod_char_traits.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/pointer.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/pool_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/rb_tree /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/random /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/random.tcc /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/rope /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/ropeimpl.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/slist /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/string_conversions.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/throw_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/typelist.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/type_traits.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/rc_string_base.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/sso_string_base.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/vstring.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/vstring.tcc /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/vstring_fwd.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/vstring_util.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/backward/hash_set /Users/fx/devel/gcc/trunk/libstdc++-v3/include/backward/hash_map .

and:

>cd ./ext && ln -s /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/algorithm /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/aligned_buffer.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/alloc_traits.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/atomicity.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/array_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/bitmap_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/cast.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/cmath /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/codecvt_specializations.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/concurrence.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/debug_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/enc_filebuf.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/extptr_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/stdio_filebuf.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/stdio_sync_filebuf.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/functional /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/iterator /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/malloc_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/memory /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/mt_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/new_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/numeric /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/numeric_traits.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/pod_char_traits.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/pointer.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/pool_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/rb_tree /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/random /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/random.tcc /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/rope /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/ropeimpl.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/slist /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/string_conversions.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/throw_allocator.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/typelist.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/type_traits.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/rc_string_base.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/sso_string_base.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/vstring.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/vstring.tcc /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/vstring_fwd.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/ext/vstring_util.h /Users/fx/devel/gcc/trunk/libstdc++-v3/include/backward/hash_set /Users/fx/devel/gcc/trunk/libstdc++-v3/include/backward/hash_map .

Presumably for the i386 and x86_64 multilibs (does it make any
difference if you do --disable-multlib? It would be easier to debug the
output if each command was only done once).

There is no "echo 1 > stamp-ext" line, but that's because the recipe
uses @$(STAMP) stamp-ext and I didn't tell you to remove the @. In any
case, we can see the symlink being created, without any errors
printed, and yet it's not there when needed. How can the "ln" command
fail?

The last change I asked you to test should have ensured that the
stamp-ext target completed before the PCH generation, but you said
that didn't help. Is something removing those symlinks after they're
created? The .PRECIOUS: target should prevent that.

I can't really do much more by email, somebody with access to one of
these failing systems needs to debug this. The problem has nothing to
do with C++ so I don't see why it needs to be solved by libstdc++
people -- just modify the makefile and inspect the results.

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-24 15:06             ` Jonathan Wakely
@ 2017-10-24 15:22               ` FX
  2017-10-24 15:47                 ` Jonathan Wakely
  0 siblings, 1 reply; 20+ messages in thread
From: FX @ 2017-10-24 15:22 UTC (permalink / raw)
  To: Jonathan Wakely; +Cc: Mike Stump, gcc patches, libstdc++

> Presumably for the i386 and x86_64 multilibs (does it make any
> difference if you do --disable-multlib? It would be easier to debug the
> output if each command was only done once).

Same problem without multilib.

> I can't really do much more by email, somebody with access to one of
> these failing systems needs to debug this. The problem has nothing to
> do with C++ so I don't see why it needs to be solved by libstdc++
> people -- just modify the makefile and inspect the results.

Thanks for the help so far. If I could debug this I would, but the complexity of this build machinery puts it out of my reach.

FX

^ permalink raw reply	[flat|nested] 20+ messages in thread

* Re: [libstdc++, patch] Fix build on APFS file system
  2017-10-24 15:22               ` FX
@ 2017-10-24 15:47                 ` Jonathan Wakely
  0 siblings, 0 replies; 20+ messages in thread
From: Jonathan Wakely @ 2017-10-24 15:47 UTC (permalink / raw)
  To: FX; +Cc: Mike Stump, gcc patches, libstdc++

On 24/10/17 17:14 +0200, FX wrote:
>> Presumably for the i386 and x86_64 multilibs (does it make any
>> difference if you do --disable-multlib? It would be easier to debug the
>> output if each command was only done once).
>
>Same problem without multilib.

OK good, so then test without multilib, because there's half as much
output to examine.

>> I can't really do much more by email, somebody with access to one of
>> these failing systems needs to debug this. The problem has nothing to
>> do with C++ so I don't see why it needs to be solved by libstdc++
>> people -- just modify the makefile and inspect the results.
>
>Thanks for the help so far. If I could debug this I would, but the complexity of this build machinery puts it out of my reach.

It's "only" a bunch of shell commands :-)

^ permalink raw reply	[flat|nested] 20+ messages in thread

end of thread, other threads:[~2017-10-24 15:47 UTC | newest]

Thread overview: 20+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2017-10-18 15:08 [libstdc++, patch] Fix build on APFS file system FX
2017-10-18 20:59 ` Petr Ovtchenkov
2017-10-18 21:05   ` FX
2017-10-18 21:17 ` Jonathan Wakely
2017-10-18 22:22   ` FX
2017-10-19  8:43     ` Richard Biener
2017-10-19  8:49       ` FX
2017-10-19 10:28       ` Petr Ovtchenkov
2017-10-19  0:28   ` Jonathan Wakely
2017-10-18 23:20 ` Hans-Peter Nilsson
2017-10-19  1:11   ` Jonathan Wakely
2017-10-23 17:44 ` Mike Stump
2017-10-23 17:55   ` FX
2017-10-23 18:02     ` Jonathan Wakely
2017-10-24  9:08       ` FX
2017-10-24 13:50         ` Jonathan Wakely
2017-10-24 14:19           ` FX
     [not found]           ` <1B1E8CBD-E34E-415A-A5D7-FB3AACA72749@gmail.com>
2017-10-24 15:06             ` Jonathan Wakely
2017-10-24 15:22               ` FX
2017-10-24 15:47                 ` Jonathan Wakely

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).