Date: Fri, 25 Nov 2016 17:17:24 -0800 From: Mark Millard <markmi@dsl-only.net> To: Dimitry Andric <dim@FreeBSD.org> Cc: svn-ports-head@freebsd.org, FreeBSD Ports <freebsd-ports@freebsd.org>, Gerald Pfeifer <gerald@FreeBSD.org> Subject: Re: svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?] Message-ID: <5C936BA8-6941-431A-B05F-31030816F85C@dsl-only.net> In-Reply-To: <9D54F0CC-F38C-4CCE-BC33-25C1457BD44B@FreeBSD.org> References: <86C72DB2-B9ED-4512-A88C-BD1D9A23806F@dsl-only.net> <9D54F0CC-F38C-4CCE-BC33-25C1457BD44B@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2016-Nov-25, at 5:00 PM, Dimitry Andric <dim@FreeBSD.org> wrote: > On 26 Nov 2016, at 01:13, Mark Millard <markmi@dsl-only.net> wrote: >> >>> Author: dim (src committer) >>> Date: Fri Nov 25 12:54:01 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: >>> . . . >>> 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. >> >> Will lang/gcc49 needs similar changes? > > Actually, the patch was copied from the lang/gcc49 port, which had > already been fixed earlier, in r421625. Good to know. >> (I normally only use explicitly version numbered lang/gcc* 's and >> I use lang/gcc49 on powerpc64's.) > > Well, lang/gcc is a special case, in the sense that some ports that have > USE_GCC=yes, e.g. with an unspecified version, will default to it. I wonder if that leaves lang/gcc and lang/gcc49 as conflicting. But luckily so far I've not picked to build anything that built lang/gcc. Or, more likely(?), if some gcc is already installed it is used instead if lang/gcc is not installed yet. I tend to install an explicit (not older) lang/gcc* first, before building much else. [Another example of conflicts can be powerpc64-gcc vs. a sometimes matching version of devel/gcc* in the same powerpc64 environment. For my activity I give priority to powerpc64-gcc despite it needing a workaround to finish installing it in a powerpc64 environment.] > -Dimitry Thanks for all the projects/clang390-import work and powerpc64 and powerpc back-porting to 3.9.0. Now I've got some testing/exploring to do in powerpc64 and powerpc lands. === Mark Millard markmi at dsl-only.net
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?5C936BA8-6941-431A-B05F-31030816F85C>