Opened 7 years ago
Closed 7 years ago
#54900 closed defect (duplicate)
libgcc @7.2.0: fatal error: bits/regex_scanner.tcc: No such file or directory
Reported by: | cjones051073 (Chris Jones) | Owned by: | |
---|---|---|---|
Priority: | Normal | Milestone: | |
Component: | ports | Version: | 2.4.1 |
Keywords: | highsierra | Cc: | smeingast (Stefan Meingast), grimreaper (Eitan Adler), Schamschula (Marius Schamschula), sbutler (Stephen J. Butler) |
Port: | libgcc |
Description (last modified by mf2k (Frank Schima))
Running newly release macOS 10.13. Xcode and CLI tools fully updated.
building libgcc gives
:info:build from /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc7/libgcc/work/gcc-7.2.0/libstdc++-v3/include/precompiled/stdc++.h:110: :info:build /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc7/libgcc/work/build/x86_64-apple-darwin17/libstdc++-v3/include/bits/regex_scanner.h:272:10: fatal error: bits/regex_scanner.tcc: No such file or directory :info:build #include <bits/regex_scanner.tcc>
Full log attached.
Port has no maintainer, so not sure who to cc. Looks similar though to ticket:54829
Attachments (3)
Change History (20)
Changed 7 years ago by cjones051073 (Chris Jones)
Attachment: | main.log.bz2 added |
---|
comment:1 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Keywords: | highsierra added |
---|---|
Summary: | libgcc - Build failure with macOS 10.13 → libgcc @7.2.0: fatal error: bits/regex_scanner.tcc: No such file or directory |
comment:2 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
Cc: | smeingast grimreaper added |
---|
comment:3 Changed 7 years ago by Schamschula (Marius Schamschula)
Cc: | Schamschula added |
---|
comment:4 Changed 7 years ago by cjones051073 (Chris Jones)
There appears to be a non-reproducible nature to the failure. I have run the build a few times now and each time the exact error is slightly different. Its in roughly the same place, and relates to an "bits/XYZ" include, but not exactly the same include each time. For instance
:info:build /opt/local/var/macports/build/_Users_chris_Projects_MacPorts_ports_lang_gcc7/libgcc/work/build/x86_64-apple-darwin17/libstdc++-v3/include/string:41:10: fatal error: bits/allocator.h: No such file or directory :info:build #include <bits/allocator.h> :info:build ^~~~~~~~~~~~~~~~~~
Could this be an APFS issue (the machine I am using was updated to the new filesystem). I ran checks with the betas version prior to the release, in a VM, and the only difference I can think of is that VM was not using APFS but the old file system...
comment:5 Changed 7 years ago by sbutler (Stephen J. Butler)
Cc: | sbutler added |
---|
Changed 7 years ago by cjones051073 (Chris Jones)
Attachment: | main2.log.bz2 added |
---|
comment:6 Changed 7 years ago by ryandesign (Ryan Carsten Schmidt)
The High Sierra buildbot worker will be set up with HFS+ so we can see if it succeeds there.
comment:7 Changed 7 years ago by cjones051073 (Chris Jones)
I have a number of my own VMs, from 10.6 onwards that I use for testing. I am in the process of cloning the macOS 10.12 one to a new 10.13 instance, so I will also be able to test this...
comment:8 Changed 7 years ago by mf2k (Frank Schima)
Description: | modified (diff) |
---|
comment:9 Changed 7 years ago by jwhowarth
I believe you are running into https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81797 which occurs on APFS volumes. The issue appears be the fine granularity of the new filesystem breaking the time stamping scheme used in the install-headers section of libstdc++-v3/include/Makefile.in (which is based on the existence of directories and not their population state). The workaround is to use the change...
diff -uNr gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in gcc-7.2.0/libstdc++-v3/include/Makefile.in --- gcc-7.2.0.orig/libstdc++-v3/include/Makefile.in 2017-07-25 14:05:07.000000000 -0400 +++ gcc-7.2.0/libstdc++-v3/include/Makefile.in 2017-09-02 12:22:08.000000000 -0400 @@ -1764,6 +1764,8 @@ @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>,
comment:10 Changed 7 years ago by cjones051073 (Chris Jones)
Thanks for that bug report. Looks like exactly what I am seeing.
I'll see if I can roll an update to add the workaround you mention above.
comment:11 Changed 7 years ago by kencu (Ken)
note that this might start to show up on other gcc* builds with APFS file systems as well. disabling parallel builds would be the easy but tedious solution.
comment:12 Changed 7 years ago by cjones051073 (Chris Jones)
Indeed. The gcc bug tracker above has a report that gcc6 at least was affected.
Assuming my ongoing libgcc (gcc7) build works I was going to look to making a similar patch for gcc6 and gcc5 and then submit a pull request for these. I am not sure if anything older is needed (or even builds) on macOS 10.13...
comment:13 Changed 7 years ago by kencu (Ken)
there are some other gcc-like ports as well in MacPorts that will likely be affected too. upc
for one...
comment:14 Changed 7 years ago by cjones051073 (Chris Jones)
Lets start with the gcc ports... These are dependencies for a number of others so first fix these and then move on...
comment:15 Changed 7 years ago by cjones051073 (Chris Jones)
OK, libgcc and gcc7 built fine with the above patch. I'll submit an update for this shortly.
Unfortunately a similar fix fo gcc6 does not seem to work. See attached build log. If anyone has any ideas o this I would like to hear ?
Chris
Changed 7 years ago by cjones051073 (Chris Jones)
Attachment: | gcc6.log.bz2 added |
---|
comment:16 Changed 7 years ago by cjones051073 (Chris Jones)
comment:17 Changed 7 years ago by jeremyhu (Jeremy Huddleston Sequoia)
Resolution: | → duplicate |
---|---|
Status: | new → closed |
Supersedes #54400.