> On Nov 8, 2018, at 2:41 AM, Landry Breuil <lan...@openbsd.org> wrote:
>
>> On Wed, Nov 07, 2018 at 10:31:20PM +0100, Christian Weisgerber wrote:
>> Brad Smith:
>>
>>> Please put this diff to switch to GCC 6 through a bulk build.
>>
>> (Full diff reproduced at the end of this message.)
>>
>> I can report these results after running a test build on amd64:
>>
>> * I don't know if this is expected, but something still pulls in
>> gcc/4.9.
>>
>> * lang/gprolog hung.
>> gplc -c --fast-math fd2c.pl
>> KILLED: build stuck at 47% frozen for 60mn
interesting. i can take a look into this one at some point soon.
>>
>> * Some ports depending on devel/riscv-elf/gcc can't be built because
>> it conflicts with gcc/6,-libs:
>> /usr/local/lib/libcc1.la (gcc-libs-6.4.0p2 and riscv-elf-gcc-8.1.0p0)
>> /usr/local/lib/libcc1.so.0.0 (gcc-libs-6.4.0p2 and riscv-elf-gcc-8.1.0p0
>>
>> * Some ports depending on devel/avr/gcc can't be built because it
>> conflicts with gcc/6,-libs:
>> /usr/local/lib/libcc1.la (gcc-libs-6.4.0p2 and avr-gcc-5.4.0p1)
>> /usr/local/lib/libcc1.so.0.0 (gcc-libs-6.4.0p2 and avr-gcc-5.4.0p1)
>>
>> (Obviously this implies that riscv-elf/gcc and avr/gcc already
>> conflict with each other. A known problem.)
>>
>> That's it on amd64.
>>
>> The much bigger question is how gcc6 will fare on the non-clang
>> archs that would use if for all C++ ports. In principle I agree
>> that gcc4.9 is too old and a new compiler will be required for newer
>> C++ code. In practice, I don't know who can take charge of this
>> change.
>
> It all boils down to what we want to do with those archs. Right now, it
> takes ~3 weeks to produce a set of packages that are more or less
> useless when they reach the mirrors, as libraries in base have been
> bumped.
>
> So yes, i can put this diff in the next sparc64 & powerpc bulks, but
> given that we're still dealing with the fallout of the move to 4.9 for
> g++ (mariadb & aspell still being the ones that take out the most) i
> doubt that many people will actually look at the failures.
i would be interested to look (and do look at the !x86 bulk logs quite a bit
actually).
> I'm running
> the bulks, the results & failure logs are public, from that point anyone
> caring can have a look.
> I'm not going to be this anyone .. brad, since
> you're pushing for this diff, are you volunteering to take care of the
> fallout ?
even if we don’t move to gcc 6 now, there might be value in running such a bulk
build because we might find problems that gcc 4.9 is missing but are real
problems in the current setup. so i think this would be a very useful
experiment and at the very least we might find out some places where
portability can be improved.
>
> Landry
>