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
> 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 fa
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 includ
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
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
-
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 -nost
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 hav
> 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
advic
On Oct 18, 2017, at 7:51 AM, 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.c
On Thu, 19 Oct 2017 10:37:14 +0200
Richard Biener wrote:
> On Wed, Oct 18, 2017 at 11:58 PM, FX 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:
> >
> > In
> 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-dar
On Wed, Oct 18, 2017 at 11:58 PM, FX 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
> =
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):
http
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):
http
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
> 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/inc
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
Th
> 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
On Wed, 18 Oct 2017 16:51:37 +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_
19 matches
Mail list logo
