https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #82 from Jens-S. Vöckler ---
I had some prior issues with w.r.t 32bits. Tinkering, this script does build a
gcc 9.1 on macOS 10.14.5 on APFS. I didn't create it for beauty, and it's
specific to my setup. The resulting compiler is unab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #81 from Jonathan Wakely ---
Basically we think there's a bug in the APFS filesystem, nobody can reproduce
it on other systems, none of us have access to such a system. It would be
really helpful if somebody seeing the error could inv
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #80 from Jonathan Wakely ---
And the headers in $target/libstdc++-v3/include/bits are now regular files, not
symlinks?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #79 from Damien Merenne ---
not -j1. Only the LN_S trick.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #78 from Jonathan Wakely ---
And is that using LN_S="cp -pR" ? And -j1 ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #77 from Damien Merenne ---
I reproduced it twice, last time with:
libtool: compile:
/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/testing/build/743cf0321be3152777da4d05247a66d1552e70a2/build/gcc-final/./gcc/xgc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #76 from Jonathan Wakely ---
And our best guess is still that Apple's new filesystem has a bug.
Does it work if you use this? make LN_S="cp -pR"
If that works, we can change the makefiles to copy files on darwin, instead of
using s
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #75 from Damien Merenne ---
Indeed in my previous comment the bug seemed to be something else, but I just
reproduced the original bug:
In file included from
/Users/dam/.conan/data/arm_none_eabi_gcc_installer/9.1.0/bloomlife/dev/build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #74 from Damien Merenne ---
Oh yeah, I forgot to mention it is building with -j1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #73 from Jens-S. Vöckler ---
I agree with Damien Merenne: I recently tried to build gcc 8 on High Sierra on
an APFS in various ways, and it failed every time. I used my old work-around of
creating an HFS+ partition-in-a-file to build
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #72 from Jonathan Wakely ---
(In reply to Damien Merenne from comment #71)
> enable-execute-stack.c:25:10: fatal error: sys/mman.h: No such file or
> directory
That's a completely different error. That header is not part of GCC.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Damien Merenne changed:
What|Removed |Added
CC||dam at cosinux dot org
--- Comment #71
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #70 from Jonathan Wakely ---
Drat, that is one of the symlinked files.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #69 from Chris Johns ---
(In reply to Jonathan Wakely from comment #68)
> (In reply to Chris Johns from comment #67)
> > (In reply to Jonathan Wakely from comment #66)
> > > Yes, I was afraid the RTEMS failures might be a different pr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #68 from Jonathan Wakely ---
(In reply to Chris Johns from comment #67)
> (In reply to Jonathan Wakely from comment #66)
> > Yes, I was afraid the RTEMS failures might be a different problem.
> >
> > Are the symptoms the same? i.e. m
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #67 from Chris Johns ---
(In reply to Jonathan Wakely from comment #66)
> Yes, I was afraid the RTEMS failures might be a different problem.
>
> Are the symptoms the same? i.e. missing C++ standard library headers?
>
Yes it seems t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #66 from Jonathan Wakely ---
Yes, I was afraid the RTEMS failures might be a different problem.
Are the symptoms the same? i.e. missing C++ standard library headers?
Comment 17 suggests you're seeing missing libgcc headers, which is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #65 from Chris Johns ---
I am still seeing this issue with the patch
https://gcc.gnu.org/ml/gcc-patches/2018-02/msg00933.html applied to gcc-7.3.0
(RTEMS 5 [master]) tool builds. This is on Mojave and an fully updated Xcode.
The ARM t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Jonathan Wakely changed:
What|Removed |Added
Target Milestone|6.4 |6.5
--- Comment #64 from Jonathan Wake
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Jonathan Wakely changed:
What|Removed |Added
Status|ASSIGNED|RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #62 from Jonathan Wakely ---
Author: redi
Date: Mon Feb 19 17:02:38 2018
New Revision: 257811
URL: https://gcc.gnu.org/viewcvs?rev=257811&root=gcc&view=rev
Log:
PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin
Back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #61 from Jonathan Wakely ---
Author: redi
Date: Mon Feb 19 16:02:38 2018
New Revision: 257808
URL: https://gcc.gnu.org/viewcvs?rev=257808&root=gcc&view=rev
Log:
PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin
Back
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #60 from Francois-Xavier Coudert ---
(In reply to Jonathan Wakely from comment #59)
> Should be fixed on trunk, please test and confirm.
Confirmed fixed on trunk. Many thanks.
Could you please backport to gcc-7-branch and gcc-6-bran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #59 from Jonathan Wakely ---
Should be fixed on trunk, please test and confirm.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #58 from Jonathan Wakely ---
Author: redi
Date: Thu Feb 15 20:56:41 2018
New Revision: 257710
URL: https://gcc.gnu.org/viewcvs?rev=257710&root=gcc&view=rev
Log:
PR libstdc++/81797 Add .NOTPARALLEL to include/Makefile for darwin
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #57 from Jens-S. Vöckler ---
(In reply to Francois-Xavier Coudert from comment #56)
> I would advise to keep it simple.
Agreed: Simple is better.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #56 from Francois-Xavier Coudert ---
(In reply to Jens-S. Vöckler from comment #55)
> Would it be worthwhile to limit it to "darwin" *and* "apfs" on objdir?
There is very little downside to applying on all darwin systems (negligible
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #55 from Jens-S. Vöckler ---
Would it be worthwhile to limit it to "darwin" *and* "apfs" on objdir? I am
thinking of something along the lines of
diskutil info $(stat -f '%Sd' /path/to/objdir) | \
perl -lane 'print $F[$#F] if /^
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #54 from Francois-Xavier Coudert ---
Thanks! Given that it affects bootstrap, maybe I ask that it be included in all
active branches?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Jonathan Wakely changed:
What|Removed |Added
Status|NEW |ASSIGNED
Assignee|unassigned
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #52 from Francois-Xavier Coudert ---
Jonathan,
Would the patch in comment 42 be acceptable? I'm suggesting it as an interim
fix, limited to the known affected build triplets while get somehow get Apple
to fix the APFS issue, so that
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #51 from Jonathan Wakely ---
The patch in comment 45 is not acceptable for all platforms.
I'll entertain a patch that only affects the broken platforms, but not
something that will end up being carried around forever and for platform
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #50 from Chris Johns ---
I raised an Apple bug report last December, the number is 36163995. Nothing
useful has happened. I will ping the bug and ask what is happening.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #49 from Campbell ---
I can confirm that the latest gcc 8 snapshot still fails by default, but it
works with 8 cores using Chris's fix above of replacing ln -s with cp. This in
my mind pretty conclusively points to it not being a make
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Jens-S. Vöckler changed:
What|Removed |Added
CC||jens4303 at me dot com
--- Comment #48
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Ryan Schmidt changed:
What|Removed |Added
CC||gcc at ryandesign dot com
--- Comment #47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #46 from Jonathan Wakely ---
Thanks, Chris. It seems like APFS probably has a bug where the dentries for
symlinks are not flushed to disk, and so later attempts to open the file fail.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #45 from Chris Johns ---
This simple hack as a test works for me with `-j 8` on an i7 without
.NOTPARALLEL:
--- gcc-7.2.0/libstdc++-v3/include/Makefile.am.orig 2017-10-27
15:30:16.0 +1100
+++ gcc-7.2.0/libstdc++-v3/includ
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #44 from Chris Johns ---
(In reply to Jonathan Wakely from comment #42)
> I think something else is going on here, and not a race condition in the
> makefile.
I agree. I see the failure after a few files have been built.
>
> This w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #43 from Jonathan Wakely ---
(In reply to Misty De Meo from comment #41)
> I requested a suggestion from Apple as to how to fix this, and was directed
> to the developer technical support page:
> https://developer.apple.com/support/te
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #42 from Jonathan Wakely ---
(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 n
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #41 from Misty De Meo ---
I requested a suggestion from Apple as to how to fix this, and was directed to
the developer technical support page:
https://developer.apple.com/support/technical/ Would you like me to file a
support request,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #40 from Campbell ---
(In reply to Chris Johns from comment #38)
> FYI I do not see any build errors with the same version of MacOS on
> different hardware running HPFS. It is a different machine with a Fusion
> disk and that disk is
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #39 from Jonathan Wakely ---
Using .NOTPARALLEL is definitely not an acceptable solution.
**Maybe** using it for affected targets only would be acceptable. Using it for
all targets is not.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #38 from Chris Johns ---
(In reply to Jonathan Wakely from comment #36)
> Also, this strongly suggests the problem for RTEMS is different:
>
> (In reply to Chris Johns from comment #24)
> > I would welcome a patch attached to this ti
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #37 from Francois-Xavier Coudert ---
(In reply to Jonathan Wakely from comment #35)
> Can somebody confirm the links are not only present, but point to the
> relevant file in the source tree?
It seems OK:
In file included from
/User
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #36 from Jonathan Wakely ---
Also, this strongly suggests the problem for RTEMS is different:
(In reply to Chris Johns from comment #24)
> I would welcome a patch attached to this ticket.
>
> My efforts with .NOTPARALLEL cannot get
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #35 from Jonathan Wakely ---
(In reply to Jonathan Wakely from comment #34)
> 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,
> whi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #34 from Jonathan Wakely ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #33 from Jonathan Wakely ---
(In reply to Marc Glisse from comment #28)
> Generally, I don't understand why we are linking sources in the build
> directory instead of passing -I flags pointing directly to the source
> directory.
I th
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #32 from Marc Glisse ---
(In reply to Misty De Meo from comment #31)
> For what it's worth, Apple's response was: "We analyzed the issue and
> determined the problem to be a latent bug in gcc’s build system that is
> revealed by chang
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #31 from Misty De Meo ---
> If --disable-libstdcxx-pch works (does it?), and until someone can
> investigate more, I'd be tempted to consider it a mac bug and recommend that
> option in https://gcc.gnu.org/install/specific.html .
F
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #30 from Marc Glisse ---
(In reply to Francois-Xavier Coudert from comment #29)
> 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
> fo
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #29 from Francois-Xavier Coudert ---
As suggested by Marc, 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_
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #28 from Marc Glisse ---
I am also failing to see how this can happen without a bug in make or macos.
The failing command is the recipe for ${pch1b_output}. That rule has
${allstamped} as a dependency, which includes stamp-bits-sup, w
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #27 from Chris Johns ---
(In reply to Jack Howarth from comment #25)
> (In reply to Chris Johns from comment #24)
> Doesn't cross-compiles set GLIBCXX_HOSTED_FALSE such that install-data-local
> is set to install-freestanding-headers
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #26 from Jonathan Wakely ---
No, cross-compiles are not automatically freestanding, and .NOTPARALLEL ignores
any prerequisites, so it makes no difference whether you say
.NOTPARALLEL: install-freestanding-headers
or
.NOTPARALLEL: i
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #25 from Jack Howarth ---
(In reply to Chris Johns from comment #24)
> I would welcome a patch attached to this ticket.
>
> My efforts with .NOTPARALLEL cannot get RTEMS's cross-compiled tools to
> build. I have seen a build work ho
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #24 from Chris Johns ---
I would welcome a patch attached to this ticket.
My efforts with .NOTPARALLEL cannot get RTEMS's cross-compiled tools to build.
I have seen a build work however most fail with a range of headers that can
var
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #23 from Francois-Xavier Coudert ---
(In reply to Jonathan Wakely from comment #22)
> So maybe somebody should submit the patch to the mailing lists.
Submitted: https://gcc.gnu.org/ml/libstdc++/2017-10/msg00045.html
Sorry I didn't d
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #22 from Jonathan Wakely ---
So maybe somebody should submit the patch to the mailing lists.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Campbell changed:
What|Removed |Added
CC||rlcamp.pdx at gmail dot com
--- Comment #21 f
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #20 from Chris Johns ---
I have been testing the patch attached to RTEMS ticket
https://devel.rtems.org/ticket/3171 and it has built gcc once for ARM and then
it did not build for SPARC plus SPARC build can fail on different header fi
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #19 from Chris Johns ---
(In reply to Francois-Xavier Coudert from comment #18)
> Adding ".NOTPARALLEL: install-headers" to the libstdc++ Makefile fixes it
> perfectly, from what we can see on our apple-darwin test machines. We've now
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Francois-Xavier Coudert changed:
What|Removed |Added
Component|target |libstdc++
--- Comment #18 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Misty De Meo changed:
What|Removed |Added
CC||misty at brew dot sh
--- Comment #3 from
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #13 from Jack Howarth ---
(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 differen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #12 from Francois-Xavier Coudert ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #11 from Jack Howarth ---
(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 granular
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #10 from Francois-Xavier Coudert ---
(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=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #9 from Jack Howarth ---
(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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #8 from Francois-Xavier Coudert ---
Can reproduce with GNU Make 4.2.1, on the same system.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #7 from Francois-Xavier Coudert ---
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++-v
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #6 from Francois-Xavier Coudert ---
(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/bugzilla/show_bug.cgi?id=81797
--- Comment #5 from Francois-Xavier Coudert ---
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/
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Francois-Xavier Coudert changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
Jack Howarth changed:
What|Removed |Added
CC||howarth.at.gcc at gmail dot com
--- Comme
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #2 from Jonathan Wakely ---
Do you have the file $target/libstdc++-v3/include/stamp-bits-sup ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797
--- Comment #1 from Jonathan Wakely ---
I don't see how this can happen, that header is present in the libstdc++ source
tree and there's nothing target-specific about it.
79 matches
Mail list logo
