Guido van Rossum wrote: > > > Side note: I recently found that the socket module is using > > bleeding edge glibc APIs as well, in fact it was the only > > module that needed the most recent glibc version installed > > on my machine (2.1.2). > > Which API? Rechecking the .so file with ldd and nm showed that the problem was due to the linker using a more current version of gethostbyname_r it found in GLIBC 2.1.2 rather than the one in GLIBC 2.1. > > All other modules were happy with plain glibc 2.1. I found > > out about this when installing an application on RedHat which > > didn't have glibc 2.1.2 installed. > > > > This may be a marginal problem, but do we really need to > > live on the bleeding edge of C libraries ? And if so, is > > there a way to configure Python to only use, say, glibc 2.1 > > APIs (to enhance binary compatibility) ? > > If we're using bleeding edge APIs, they should be properly tested for > in configure.in and the code should use #ifdef. Agreed. In this case, I think, it was a false alarm though, since AFAIK, we can't tell the linker to only use one GLIBC version (_socket.so links to APIs from three different versions on my machine: GLIBC 2.0, 2.1 and 2.1.2). BTW, the man-page for ld mentions an optimization option -On -- does anyone know what the affect of this option is and whether its GNU specific ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4