Re: GCC and binutils updates for buster

2018-08-14 Thread Manuel A. Fernandez Montecelo
2018-08-13 04:25 Paul Wise: On Mon, Aug 13, 2018 at 1:19 AM, Manuel A. Fernandez Montecelo wrote: 2018-07-30 22:36 Adrian Bunk: And the next burden will be if riscv64 gets added in bullseye. [*] Unlike other arches, this one is not restricted to a single vendor so hardware can be annouced

Re: GCC and binutils updates for buster

2018-08-12 Thread Paul Wise
On Mon, Aug 13, 2018 at 1:19 AM, Manuel A. Fernandez Montecelo wrote: > 2018-07-30 22:36 Adrian Bunk: >> >> And the next burden will be if riscv64 gets added in bullseye. > > [*] Unlike other arches, this one is not restricted to a single vendor >so hardware can be annouced at any time from une

Re: GCC and binutils updates for buster

2018-08-12 Thread Manuel A. Fernandez Montecelo
2018-07-30 22:36 Adrian Bunk: And the next burden will be if riscv64 gets added in bullseye. Not likely, I think, since for example there's almost no hardware available for end-users to buy (or to use for buildds), and this will probably be the case at least until the freeze [*]. Another reas

Re: GCC and binutils updates for buster

2018-07-30 Thread Adrian Bunk
On Mon, Jul 16, 2018 at 05:59:28PM +0200, Matthias Klose wrote: >... > - armel: The armv4t default isn't used very much anymore, The baseline is armv5te since last year. > and we had issues in the past. Could you elaborate on that? The latest major issue I am aware of was about #727621 and the

Re: GCC and binutils updates for buster

2018-07-18 Thread Sebastian Andrzej Siewior
On 2018-07-16 17:59:28 [+0200], Matthias Klose wrote: > architectures. Some notes on other candidates for release architectures: > > - armel: The armv4t default isn't used very much anymore, and we had >issues in the past. Would things get better with armv5te as default or is the lack of FP

GCC and binutils updates for buster

2018-07-17 Thread Matthias Klose
GCC 8 is available in testing/unstable, and upstream is approaching the first point release. I am planning to make GCC 8 the default at the end of the week (gdc and gccgo already point to GCC 8). Most runtime libraries built from GCC are already used in the version built from GCC 8, so I don't ex