Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 07 Sep 2016 21:29:45 +0000
From:      bugzilla-noreply@freebsd.org
To:        freebsd-ports-bugs@FreeBSD.org
Subject:   [Bug 212465] lang/gcc49: Fix build with libc++ 3.9.0
Message-ID:  <bug-212465-13@https.bugs.freebsd.org/bugzilla/>

next in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D212465

            Bug ID: 212465
           Summary: lang/gcc49: Fix build with libc++ 3.9.0
           Product: Ports & Packages
           Version: Latest
          Hardware: Any
                OS: Any
            Status: New
          Severity: Affects Some People
          Priority: ---
         Component: Individual Port(s)
          Assignee: gerald@FreeBSD.org
          Reporter: dim@FreeBSD.org
          Assignee: gerald@FreeBSD.org
             Flags: maintainer-feedback?(gerald@FreeBSD.org)

Created attachment 174492
  --> https://bugs.freebsd.org/bugzilla/attachment.cgi?id=3D174492&action=
=3Dedit
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_NORETUR=
N;
            ^
1 error generated.

What is happening here, is that the source file includes gcc/system.h, whic=
h=20
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::).  T=
he
macro definition then causes the above breakage.

Newer gcc ports, such as gcc5 and gcc6 don't show this issue, because upstr=
eam
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=3Drevision&revision=3D217348
[2] https://gcc.gnu.org/viewcvs/gcc?view=3Drevision&revision=3D232736

--=20
You are receiving this mail because:
You are the assignee for the bug.=



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-212465-13>