Martin v. Löwis wrote:
> 
> Martin v. Löwis <martin@v.loewis.de> added the comment:
> 
>> Well, it is important to somehow get the build information for
>> Python, since that tells us which OS features were available
>> at the time of compilation.
> 
> 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.

But even for Linux, the header information gets dumped into the
plat-linuxN directory files, and those change over time as well.
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.

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.

For other OSes, the build version is much more important due
to the significant changes they make between releases, e.g.
Mac OS X.

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

The problem with those is that some distros choose to only
include those files in -dev packages and parsing them via
sysconfig just to get a quick look at the platform build
version is really a bit too much processing.

> Since there is no chance that we get the build environment captured
> in a reasonable way (in particular not the version of the C library,
> in a cross-platform manner), I strongly recommend to let this aspect
> rest.

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.

The platform module provides a way to determine the
lib C version required by the running Python binary on Linux
(and perhaps other OSes as well), but it's slow.