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
