svn commit: r427110 - head/lang/gcc/files [does lang/gcc49 need such too?]

[Mark Millard]

On 2016-Nov-25, at 5:00 PM, Dimitry Andric <dim at FreeBSD.org> wrote:

> On 26 Nov 2016, at 01:13, Mark Millard <markmi at 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