Marc-Andre Lemburg <m...@egenix.com> added the comment: Martin v. Löwis wrote: > > Martin v. Löwis <mar...@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. ---------- _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue12794> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
