On 2016-02-29 15:58, Jon Masters wrote: > Indeed. The architecture contains a 32-bit backward compatible > component (that is optional in 64-bit ARM servers[0], but included in > the one that you are using) and it is technically possible to install > the libraries side by side. However the upstream that Cent is using is > intentionally engineered never to support that case. It sounds harsh > now, but there is no 32-bit server legacy, we have 32-bit VMs, you > could build a 32-bit container if you really wanted, and in a couple > of years we will all be wondering why we ever cared about 32-bit in > the first place on ARM servers. If a container should work, why does chroot not work? I don't particularly care about running things side-by-side (as per the enormous in-everyone's-face precedent of x86/x86-64), but why would running an armv5tel guest in a chroot not "just work"? > [0] That was my doing. It is time to move on from 32-bit and not > create a legacy, dragging everyone's power/performance efficiency down > having to implement expensive 32-bit backward compatibility that > people don't actually need. Recompile the software and move forward. It's far too easy to take the moral high ground when you aren't in need of closed source software that you cannot just recompile. Until a couple of months ago, the only Plex Media Server variant available for ARM was armel (ARMv4 soft-float). It'll likely be a while before they provide an aarch64 PMS binary. Additionally, it would be really handy to be able to use a big aarch64 machine with tons of RAM for building 32-bit ARM packages. Big compile jobs on the pitifully underpowered and under-RAM-ed are increasingly painful, particularly the well known bloatware such as web browsers (EL6 Firefox brings it's own GCC the build process has to build first before using it to compile FF), LibreOffice and others. Gordan