port's svn commit: r413746 - in head "many ports: mark broken on powerpc64": for what toolchains?

[Steve Wills]

I did test this, but it failed. The log is here:

http://poudriere.mouf.net/karl/poudriere/data/headpowerpc-default/2016-04-27_12h19m39s/logs/gcc6-devel-6.0.0.s20160320.log

Looks like gfortran failed to build?

Steve

On 04/24/16 01:24 PM, Steve Wills wrote:
> Hi,
> 
> On 04/24/16 10:16 AM, Mark Millard wrote:
>>
>> For all the port update activity (including ruby) I used gcc49, /etc/make.conf being:
>>
>> # more /etc/make.conf DEFAULT_VERSIONS+=perl5=5.22 
>> WRKDIRPREFIX=/usr/obj/portswork
>> WITH_DEBUG=
>> WITH_DEBUG_FILES= 
>> MALLOC_PRODUCTION=
>> #
>> #
>> # For trying gcc49...
>> # 
>> CC=/usr/local/bin/gcc49
>> CXX=/usr/local/bin/g++49 
>> CPP=/usr/local/bin/cpp49
>> . . . (binutils macros omitted here) . . .
>>
>>
>> (I do not know if lang/gcc [or lang/gcc48] would work or not. I
>> prefer a tool chain with a more modern C++ available but gcc49 is not
>> yet what lang/gcc builds.)
>>
>>
>>
>> I've seen notation like:
>>
>> USE_GCC=        4.9+
>>
>> in port Makefiles. Also notation like:
>>
>> .if ${ARCH} == powerpc64
>>
>> and:
>>
>> .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64"
>>
>>
>> So may be the extra notation in the Makefile(s) in question could be something like:
>>
>> # clang 3.8.0 and before is still broken in various ways for powerpc and powerpc64:
>> .if ${ARCH} == "powerpc" || ${ARCH} == "powerpc64"
>> USE_GCC=        4.9+
>> .endif
>>
> 
> Yep, this sounds right to me. I will test this with at least lang/ruby22
> and lang/gcc6-devel when my current build finishes, or sooner if I get
> impatient. :)
> 
> 
>> I list both powerpc variants because powerpc and powerpc64 both have
>> clang problems making buildworld a no-go by default and if gcc 4.2.1
>> rejects a port for one it would normally also reject for the other.
>> There may be other ${ARCH} values that would also be appropriate
>> because they are also stuck at gcc 4.2.1 .
> 
> Makes sense.
> 
>> I do not claim to know necessary vs. sufficient status: more might be
>> needed for some configurations (rpath issues? mixture of libraries
>> compiled by distinct gcc's?). But I expect that the above should be
>> better than being marked broken.
> 
> We'll find this out when we test! :)
> 
> Thanks,
> Steve
>