![](https://seccdn.libravatar.org/avatar/aea1d8248292e6482742234c5cb514de.jpg?s=120&d=mm&r=g)
Brian K. White wrote:
It is supported because commercial binaries cost a lot, are not practically replaceable, and are not recompilable.
Agreed. Can you name 1 that doesn't produce 64-bit compatible binaries today?
I routinely install such old 32bit-only binaries on new 64bit systems, from several different vendors, and all I need for them to work is matching 32bit libraries.
Is there anything that would prevent running the small number of those in a chroot env where only the 32-bit binaries are subbed in? -- or a VM if needed? Using namespaces, a 32-bit binary could run with it's 32-bit binaries in the normal places, and all the rest of your files in the normal place as well. No virtualization needed -- at full speed and w/full access to graphical HW (thinking Wine based graphix games)... Why wouldn't that work? Seriously, where's the problem? Is it just a matter of fixing the packaging? Certainly investing some time in such a split/cleanup would be worth it. I remember the build people having problems if they had 32 and 64-bit versions of things loaded and tried to build at the same time, but if the 32-bit stuff automatically used a 32-bit root, wouldn't those go away too? -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org