[This discussion is really off-topic for this issue, it should either
 be moved to issue12795 or a new ticket]

Martin v. Löwis wrote:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
>>> 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.

I meant that the OS platform directories change over time,
i.e. new plat-<os><version> directories get created to
hold the updated OS information.

Since Python was build on a specific OS version, it will only
see the APIs available on that OS version. The OS build
version provides a quick way to check whether a certain
set of feature is available or not.

>> 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.

This is meant to happen. The whole purpose of autoconf/configure is
to try to figure out which features are available on a platform
and those features change with the OS version.

See e.g. these documents on the incremental Linux kernel changes
between 2.2 and 3.0:

http://www.kniggit.net/wwol22.html
http://www.kniggit.net/wwol24.html
http://www.kniggit.net/wwol26.html
http://jpranevich.tripod.com/wwol30/wonderful-world-of-linux-3.0.html

Here's a similar list for FreeBSD:

http://ivoras.net/freebsd/freebsd9.html
http://ivoras.net/freebsd/freebsd8.html
http://ivoras.net/freebsd/freebsd7.html

On Mac OS X the situations is a little different: older Python
binaries simply won't run on newer OS versions at all due to the
architecture changes, so there's nothing much to check.

>> 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.

True, the feature may still not work in the runtime OS environment,
but at least the Python binary knows about the feature set you're
interested in, so you can actively check whether it works or not,
since the APIs will be available.

>>> (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).

Please don't mix up the build time environment with the
runtime environment. Using "running kernel" to refer to
the build time kernel is a rather confusing way of naming
things when discussing build time vs. runtime.

>> 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.

The platform API libc_ver() actually checks the linker references
in the binary and also allows using a different binary
for the check in case the Python binary is not a suitable
candidate.

It is mainly meant to identify the minimum lib C requirement
for a binary.

Adding the lib C version constants would make this information
more directly accessible: __GLIBC__ and __GLIBC_MINOR__ for
glibc.

Regardless, the issue is about adding a runtime query function
to the platform module, not the build time OS version information
which we currently don't provide in an easily usable way. The latter
is being discussed on issue12795 and issue12326.