[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: The (uncalled for) toolchain maintainers roll call for stretch



On 10.09.2016 10:21, Simon McVittie wrote:
> On Sat, 10 Sep 2016 at 00:48:09 +0200, Matthias Klose wrote:
>> The arm-linux-gnueabi is not that well defined, so it may include the hard float
>> variant as well.  However Debian default to armv4t, while the default
>> configuration for upstream is armv5.  However with the selected defaults
>> Debian's libstdc++::future module is not complete and causes build failures on
>> this architecture (same for sparc).
> 
> This sounds as though armhf might in fact be better-supported than armel
> in practice, because it targets armv7 which is an armv5 superset.
> 
> Devil's advocate: what supported devices would be lost if armel's baseline
> advanced from armv4t to armv5, in much the same way that x86's baseline
> recently advanced to i686?
> 
> According to the installation guide, jessie supported ixp4xx (scheduled
> to be dropped in stretch anyway), kirkwood (which I think is always armv5),
> orion5x, and versatile (qemu). In sid, the kirkwood and orion5x kernels
> have been combined into a marvell kernel which appears to use
> ARCH_MULTI_V5. ARCH_VERSATILE also depends on ARCH_MULTI_V5, so I think
> the only supported use for armel on armv4 at this point is with a
> self-compiled kernel (or another distro's kernel outside a
> container/chroot) anyway?
> 
> (Perhaps I'm just being selfish here, because my only armel device is a
> Kirkwood, which I'm fairly sure is v5 and would survive this change.)

I don't think that the move to armv5/armv5t is enough to fix issues like
#727621, for that you would need v7.

You certainly would loose support for the Raspi Pi, however the Raspian
derivative already rebuilds the armhf architecture for armv6 outside of Debian.

Matthias


Reply to: