On 12/11/2010 10:49 AM, Allan McRae wrote:

Hi,

I am in the progress of updating the toolchain and thought it time to review what our minimum required kernel version is for glibc.

For those that do not know, assuming a newer kernel allows glibc to have less workarounds compiled in. So it may be advantagous to have a more recent version as the minimum required. This comes at the obvious cost of not having support for older kernels so a tradeoff is needed... When we discussed this 18 months ago, it was decided 2.6.18 was appropraite then, but much has changed since.

I am going to suggest that we follow the oldest longterm support kernel. That would now be the 2.6.27.x series, which has been around for over two years.

That might be being overly bold, so feel free to point out how much such an update would break... and suggest an alternative minimum.

Allan

The workarounds obviously make maintainence a little more difficult, but is there a performance hit too? Could a glibc and glibc-legacy/glibc-compat type of thing be a viable solution? Then the question would be what kernel defines the line between the two glibc packages (probably -lts would be good).