Bug 212465 - lang/gcc49: Fix build with libc++ 3.9.0
Summary: lang/gcc49: Fix build with libc++ 3.9.0
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Some People
Assignee: Dimitry Andric
URL:
Keywords: needs-qa, patch
Depends on:
Blocks: 212343
  Show dependency treegraph
 
Reported: 2016-09-07 21:29 UTC by Dimitry Andric
Modified: 2017-01-31 01:00 UTC (History)
3 users (show)

See Also:
gerald: maintainer-feedback+
dim: merge-quarterly+


Attachments
Include <new> in gcc/system.h (841 bytes, patch)
2016-09-07 21:29 UTC, Dimitry Andric
koobs: maintainer-approval+
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Dimitry Andric freebsd_committer 2016-09-07 21:29:45 UTC
Created attachment 174492 [details]
Include <new> in gcc/system.h

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].

I propose to 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 it's less churn.

[1] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=217348
[2] https://gcc.gnu.org/viewcvs/gcc?view=revision&revision=232736
Comment 1 Ed Maste freebsd_committer 2016-09-07 21:33:42 UTC
sounds reasonable to me
Comment 2 Gerald Pfeifer freebsd_committer 2016-09-08 01:08:38 UTC
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 3 Kubilay Kocak freebsd_committer freebsd_triage 2016-09-08 07:44:31 UTC
Comment on attachment 174492 [details]
Include <new> in gcc/system.h

Mark maintainer approval correctly (on attachment/patch)
Comment 4 Dimitry Andric freebsd_committer 2016-09-08 20:55:49 UTC
(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.
Comment 5 commit-hook freebsd_committer 2016-09-09 18:49:22 UTC
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
Comment 6 Dimitry Andric freebsd_committer 2016-09-09 18:53:47 UTC
(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.
Comment 7 Gerald Pfeifer freebsd_committer 2016-09-11 11:48:21 UTC
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.
Comment 8 commit-hook freebsd_committer 2016-09-13 18:41:11 UTC
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
Comment 9 commit-hook freebsd_committer 2016-11-25 12:54:38 UTC
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