On Fri, Dec 04, 2015 at 10:06:11AM +0100, Aurelien Jarno wrote: > The minimum required version in the glibc is something configurable at > build time (to some extents, the absolute minimum is 2.6.32 for glibc > 2.21). This configure how much compatibility glue is used to workaround > the missing syscalls. This compatibility glue is bloating the libc, and > usually also have bugs which triggers for old kernels, but also > sometimes for new kernels. For example recently someone wanted to push > the minimum version to 3.15 to fix an issue with pthread_cond_broadcast > on ARM. > > That's the reason why historically we have always required for a glibc > from release N, at least the kernel from release N-2. This means for > stretch, the kernel from wheezy, ie 3.2. Supporting bleeding edge > software with an archaic kernel is not something easy to do, and other > parts of the distribution simply don't, especially since the switch to > systemd. I haven't tested this myself, but apparently Arch works fine[1] on OpenVZ if the host kernel is up-to-date. The installation instructions don't seem to contain any OpenVZ specific steps, so probably they're already compiling their glibc using the broadest compatibility settings. Moreover, the OpenVZ developers seem to be keen to backporting features[2] required to run modern distributions, which makes sense when you consider that their 3.10 based product is still not ready. Maybe we can make this work after all? [1] https://wiki.archlinux.org/index.php/Virtual_Private_Server [2] https://bugs.openvz.org/browse/OVZ-6384 -- Andrea Bolognani <eof@kiyuko.org> Resistance is futile, you will be garbage collected.
Attachment:
signature.asc
Description: PGP signature