Bug 212465
| Summary: | lang/gcc49: Fix build with libc++ 3.9.0 | ||||||
|---|---|---|---|---|---|---|---|
| Product: | Ports & Packages | Reporter: | Dimitry Andric <dim> | ||||
| Component: | Individual Port(s) | Assignee: | Dimitry Andric <dim> | ||||
| Status: | Closed FIXED | ||||||
| Severity: | Affects Some People | CC: | dim, emaste, gerald | ||||
| Priority: | --- | Keywords: | needs-qa, patch | ||||
| Version: | Latest | Flags: | gerald:
maintainer-feedback+
dim: merge-quarterly+ |
||||
| Hardware: | Any | ||||||
| OS: | Any | ||||||
| See Also: |
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216647 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216266 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=216303 |
||||||
| Bug Depends on: | |||||||
| Bug Blocks: | 212343 | ||||||
| Attachments: |
|
||||||
|
Description
Dimitry Andric
2016-09-07 21:29:45 UTC
sounds reasonable to me I will admit that I am not an expert here, but having verified myself that current upstream has this and based on your (very nice) analysis and explanation (thank you!), Approved: gerald (maintainer). Bonus points if you could run make full-regression-test with and without the patch and compare the output (which should match) on a system building either way, so with older libc++. Either way, I am handing over this bug to you since I assume you'll be the one doing the commit? Comment on attachment 174492 [details]
Include <new> in gcc/system.h
Mark maintainer approval correctly (on attachment/patch)
(In reply to Gerald Pfeifer from comment #2) > I will admit that I am not an expert here, but having verified myself > that current upstream has this and based on your (very nice) analysis > and explanation (thank you!), Approved: gerald (maintainer). > > Bonus points if you could run > make full-regression-test > with and without the patch and compare the output (which should match) > on a system building either way, so with older libc++. I've actually been trying this, but even without the patch, some of the tests hang, apparently when they are running some gdb script: 87914 2 I+ 12:43.21 `-- expect -- /usr/local/share/dejagnu/runtest.exp --tool g++ 65206 2 TX+ 0:00.13 |-- ./guality_check87914.exe 65208 2 I+ 0:00.44 | `-- gdb -nx -nw --quiet (gdb7111) I have to kill gdb to make the tests continue. Is that expected? The gdb binary is from the gdb port. In any case, with and without the patch, I see some differences in the test output that I can't explain. Do any two subsequent test runs with the same workdir produce the same output? It takes a very long time here, since I don't have a fast machine to run them on. > Either way, I am handing over this bug to you since I assume you'll be > the one doing the commit? Yes, I can do the commit. A commit references this bug: Author: dim Date: Fri Sep 9 18:48:24 UTC 2016 New revision: 421625 URL: https://svnweb.freebsd.org/changeset/ports/421625 Log: Fix build of lang/gcc49 with libc++ 3.9.0 While testing the clang390-import branch, I ran into the following errors building lang/gcc49: In file included from /wrkdirs/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/c/c-objc-common.c:33: In file included from /usr/include/c++/v1/new:70: /usr/include/c++/v1/exception:267:5: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~~~~~ /usr/include/c++/v1/__config:451:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ /wrkdirs/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/system.h:685:13: note: 'fancy_abort' declared here extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN; ^ 1 error generated. What is happening here, is that the source file includes gcc/system.h, which defines abort to fancy_abort, and then the source file includes <new>, which attempts to call _VSTD::abort() (the _VSTD is a libc++ alias for std::). The macro definition then causes the above breakage. Newer gcc ports, such as gcc5 and gcc6 don't show this issue, because upstream gcc first added an include of <algorithm> (which indirectly includes <new>) in r217348 [1], and later even add a direct include of <new> in r232736 [2]. Fix it for this version, by adding the direct include of <new> to gcc/system.h. This makes the 'second' includes of <new> in some .c files superfluous, but at least they won't result in errors. [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217348 [2] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=232736 Approved by: gerald (maintainer) PR: 212465 MFH: 2016Q3 Changes: head/lang/gcc49/files/patch-gcc_system.h (In reply to Dimitry Andric from comment #4) > (In reply to Gerald Pfeifer from comment #2) ... > > Bonus points if you could run > > make full-regression-test > > with and without the patch and compare the output (which should match) > > on a system building either way, so with older libc++. > > I've actually been trying this I must have done something wrong on the first few tries. I now did two full regression tests without the patch, and the output of those differed only by printed time stamps. Then I did a full regression test with the patch, and again, the output was only different in the time stamps. Yeah, sorry for not responding to your question on reproducability right away: I was taken by surprise and started to look into this from my end since usually my testresult runs are pretty reproducible. A commit references this bug: Author: dim Date: Tue Sep 13 18:41:08 UTC 2016 New revision: 422057 URL: https://svnweb.freebsd.org/changeset/ports/422057 Log: MFH: r421625 Fix build of lang/gcc49 with libc++ 3.9.0 While testing the clang390-import branch, I ran into the following errors building lang/gcc49: In file included from /wrkdirs/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/c/c-objc-common.c:33: In file included from /usr/include/c++/v1/new:70: /usr/include/c++/v1/exception:267:5: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~~~~~ /usr/include/c++/v1/__config:451:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ /wrkdirs/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/system.h:685:13: note: 'fancy_abort' declared here extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN; ^ 1 error generated. What is happening here, is that the source file includes gcc/system.h, which defines abort to fancy_abort, and then the source file includes <new>, which attempts to call _VSTD::abort() (the _VSTD is a libc++ alias for std::). The macro definition then causes the above breakage. Newer gcc ports, such as gcc5 and gcc6 don't show this issue, because upstream gcc first added an include of <algorithm> (which indirectly includes <new>) in r217348 [1], and later even add a direct include of <new> in r232736 [2]. Fix it for this version, by adding the direct include of <new> to gcc/system.h. This makes the 'second' includes of <new> in some .c files superfluous, but at least they won't result in errors. [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217348 [2] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=232736 Approved by: portmgr (feld) PR: 212465 Changes: _U branches/2016Q3/ branches/2016Q3/lang/gcc49/files/patch-gcc_system.h A commit references this bug: Author: dim Date: Fri Nov 25 12:54:02 UTC 2016 New revision: 427110 URL: https://svnweb.freebsd.org/changeset/ports/427110 Log: Fix build of lang/gcc with libc++ 3.9.0, similar to r421625: While testing the clang390-import branch, I ran into the following errors building lang/gcc49: In file included from /wrkdirs/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/c/c-objc-common.c:33: In file included from /usr/include/c++/v1/new:70: /usr/include/c++/v1/exception:267:5: error: no member named 'fancy_abort' in namespace 'std::__1'; did you mean simply 'fancy_abort'? _VSTD::abort(); ^~~~~~~ /usr/include/c++/v1/__config:451:15: note: expanded from macro '_VSTD' #define _VSTD std::_LIBCPP_NAMESPACE ^ /wrkdirs/usr/ports/lang/gcc49/work/gcc-4.9.4/gcc/system.h:685:13: note: 'fancy_abort' declared here extern void fancy_abort (const char *, int, const char *) ATTRIBUTE_NORETURN; ^ 1 error generated. What is happening here, is that the source file includes gcc/system.h, which defines abort to fancy_abort, and then the source file includes <new>, which attempts to call _VSTD::abort() (the _VSTD is a libc++ alias for std::). The macro definition then causes the above breakage. Newer gcc ports, such as gcc5 and gcc6 don't show this issue, because upstream gcc first added an include of <algorithm> (which indirectly includes <new>) in r217348 [1], and later even add a direct include of <new> in r232736 [2]. Fix it for this version, by adding the direct include of <new> to gcc/system.h. This makes the 'second' includes of <new> in some .c files superfluous, but at least they won't result in errors. [1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217348 [2] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=232736 Approved by: portmgr (antoine) PR: 212465 Changes: head/lang/gcc/files/patch-gcc_system.h |