> 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
> 

Reply via email to