>> No, it doesn't (except for a bug that Matthias Klose pointed out).
>> The OS kernel version should have *zero* impact on the resulting Python
>> binary. What matters it the C compiler and the version of the C library.
>> The C library may or may not have features; features of the kernel used
>> to build Python are completely irrelevant.
> 
> We are now discussing the general case, not limited to Linux.

And so was I. Read my statement as applying to the general case.

> But even for Linux, the header information gets dumped into the
> plat-linuxN directory files, 

Not in the build process, though...

> and those change over time as well.

What exactly changes over time? The plat-linuxN directory files?
Only if a developer updates them. For systems where the major
version indicates feature changes, the plat-OSn directory should
never change, since OS won't see any header changes until OSn+1
is released.

> The kernel version also has an impact on certain features such
> as real time clocks, timers or other kernel subsystems, which
> autoconf then picks up at compile time.

Which operating system specifically are you referring to here?
This should not happen.

> Of course, you can check whether those features are available
> one by one, but a version check is often a better way to see
> whether your application has a chance of running on the Python
> build in question.

That's a fragile approach, though. If the feature presence
varies with the OS kernel, you should rather check the version
of the kernel you are running on - it may be that support was
compiled in, but the system it runs on doesn't have that
support.

>> (I think you misunderstood an earlier statement of me as
>> self-contradicting. It was not: The kernel *headers* may have an
>> impact during autoconf, not the running kernel. For Linux, the
>> kernel headers are part of the C library, and typically bear no
>> relationship with the running kernel - i.e. they may be either older
>> or newer than the running kernel).
> 
> I'm not talking about the runtime information. I'm talking
> about the compile time build information which is available
> via the Makefile and pyconfig.h file normally stored in the Python
> installation and which is used by distutils.

And so am I. "running kernel" above refers to the kernel running
on the build system (i.e. what uname(1) gives you in autoconf,
and what currently gets into sys.platform).

> We already do capture the build environment. This doesn't include
> the C library version, but we could add that as well, if needed,
> in a more direct way.

No, we can't - that's impossible to implement in the general
case. Some systems may use static linking, or use a fixed version
number even as the library changes.