Folks, autoconf maintainers have advanced autoconf development over the last few years in slightly incompatible ways; as a result, the have produced autoconf 2.50 and successors. The generated autoconf scripts vary largely in their text, and slightly in their behaviour; autoconf 2.50 offers many additional features, also, not all configure.in scripts work with autoconf 2.50. Access to autoconf 2.13 with Linux distributions is becoming a problem, since some Linux distributors only offer 2.5x packages. So the question arises whether Python's configure should update to 2.50. In rev 1.268, I had ported configure.in to support autoconf 2.50, but have continued to use autoconf 2.13 to regenerate it. If all regular editors of configure.in have autoconf 2.5x available, or can install it, I'd propose to bump the AC_PREREQ to 2.50. For those of you who'd then need both autoconf versions available, I can recommend the Debian wrapper; this is a perl script that invokes either autoconf2.13 or autoconf2.50, depending on several criteria (configure.in or configure.ac? AC_PREREQ?). If there is interest, I can post instructions on how to install both versions side-by-side. So what do you think? Regards, Martin
Martin> If all regular editors of configure.in have autoconf 2.5x Martin> available, or can install it, I'd propose to bump the AC_PREREQ Martin> to 2.50. I believe 2.50 had serious bugs and was superceded rather quickly by the autoconf maintainers. I would vote to boost to 2.52 or above. Skip
Skip Montanaro wrote:
Martin> If all regular editors of configure.in have autoconf 2.5x Martin> available, or can install it, I'd propose to bump the AC_PREREQ Martin> to 2.50.
I believe 2.50 had serious bugs and was superceded rather quickly by the autoconf maintainers. I would vote to boost to 2.52 or above.
Does the update buy us anything ? FWIW, Suse 7.2 shipped with autoconf 2.13 and is still a rather recent Linux distro. 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.2.1). All other modules were happy with plain glibc 2.2. I found out about this when installing an application on RedHat which didn't have glibc 2.2.1 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.2 APIs (to enhance binary compatibility) ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
"mal" == mal <M.-A.> writes:
mal> Skip Montanaro wrote: >> Martin> If all regular editors of configure.in have autoconf 2.5x Martin> available, or can install it, I'd propose to bump the AC_PREREQ Martin> to 2.50. >> >> I believe 2.50 had serious bugs and was superceded rather quickly by the >> autoconf maintainers. I would vote to boost to 2.52 or above. mal> Does the update buy us anything ? Maybe not. When I was making daily builds of Gtk2 from CVS a few months ago, I needed to install autoconf 2.52. The Gtk folks use features not available in 2.13. Martin thinks there are some bug fixes. The biggest difference I see is that when I make a change to configure.in, rerun autoconf, then want to see what the resulting change to configure is, ediff reports 1355 changes instead of a small handful. If we have everyone on different versions of autoconf, configure script checkins are going to be humongous. I doubt we'll fill up the CVS disk on SF, but it still seems like we should move forward as a group when we do, particularly those folks who edit configure.in most frequently. I can't comment on glibc versions. I just go with the flow there... Skip
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.2.1).
Which API?
All other modules were happy with plain glibc 2.2. I found out about this when installing an application on RedHat which didn't have glibc 2.2.1 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.2 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. --Guido van Rossum (home page: http://www.python.org/~guido/)
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/
"M.-A. Lemburg" <mal@lemburg.com> writes:
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 ?
Yes, it is GNU specific. It currently (binutils 2.11) only supports one level of optimization, and that is only used for ELF targets. On ELF targets, if optimization is requested, the optimal table size for the symbol table is computed. Since ELF uses a hashing mechanism, the number of hash collisions depends on the table size. Under optimization, the linker tries all table sizes, and choses the one with the least collisions. Regards, Martin
"Martin v. Loewis" wrote:
"M.-A. Lemburg" <mal@lemburg.com> writes:
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 ?
Yes, it is GNU specific. It currently (binutils 2.11) only supports one level of optimization, and that is only used for ELF targets. On ELF targets, if optimization is requested, the optimal table size for the symbol table is computed. Since ELF uses a hashing mechanism, the number of hash collisions depends on the table size. Under optimization, the linker tries all table sizes, and choses the one with the least collisions.
Thanks for the explanations. Probably not worth looking at for Python, right ? -- Marc-Andre Lemburg CEO eGenix.com Software GmbH ______________________________________________________________________ Company & Consulting: http://www.egenix.com/ Python Software: http://www.egenix.com/files/python/
"M.-A. Lemburg" <mal@lemburg.com> writes:
Does the update buy us anything ?
I know of two specific aspects: - the AC_CHECK_HEADERS in autoconf 2.5x will check the status of the compiler invocation, instead of checking the error output. In turn, if gcc produces a warning for a system header, autoconf 2.13 will conclude that the headers is missing, whereas autoconf 2.5x will detect its presence. This, in turn, should fix #535545. - autoconf 2.5x supports AC_CHECK_DECL. This can help fixing #534108.
FWIW, Suse 7.2 shipped with autoconf 2.13 and is still a rather recent Linux distro.
SuSE 7.3 ships 2.52 only. It is a more recent Linux distribution.
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.2.1).
Can you give precise details?
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.2 APIs (to enhance binary compatibility) ?
It certainly does; if it doesn't, please report a bug. In any case, Python is not written specifically for glibc; it is portable across various C libraries. Regards, Martin
Folks,
autoconf maintainers have advanced autoconf development over the last few years in slightly incompatible ways; as a result, the have produced autoconf 2.50 and successors.
The generated autoconf scripts vary largely in their text, and slightly in their behaviour; autoconf 2.50 offers many additional features, also, not all configure.in scripts work with autoconf 2.50.
Access to autoconf 2.13 with Linux distributions is becoming a problem, since some Linux distributors only offer 2.5x packages. So the question arises whether Python's configure should update to 2.50.
In rev 1.268, I had ported configure.in to support autoconf 2.50, but have continued to use autoconf 2.13 to regenerate it.
If all regular editors of configure.in have autoconf 2.5x available, or can install it, I'd propose to bump the AC_PREREQ to 2.50.
For those of you who'd then need both autoconf versions available, I can recommend the Debian wrapper; this is a perl script that invokes either autoconf2.13 or autoconf2.50, depending on several criteria (configure.in or configure.ac? AC_PREREQ?). If there is interest, I can post instructions on how to install both versions side-by-side.
So what do you think?
Regards, Martin
No problem from me. autoconf 2.50 works perfectly for me. But when I downloaded and installed autoconf 2.53, this is what I got when I ran it: $ autoconf configure.in:1062: error: do not use LIBOBJS directly, use AC_LIBOBJ (see section `AC_LIBOBJ vs. LIBOBJS' Autoheader gives me a bunch of new warnings: $ autoheader WARNING: Using auxiliary files such as `acconfig.h', `config.h.bot' WARNING: and `config.h.top', to define templates for `config.h.in' WARNING: is deprecated and discouraged. WARNING: Using the third argument of `AC_DEFINE' and WARNING: `AC_DEFINE_UNQUOTED' allows to define a template without WARNING: `acconfig.h': WARNING: AC_DEFINE([NEED_MAIN], 1, WARNING: [Define if a function `main' is needed.]) WARNING: More sophisticated templates can also be produced, see the WARNING: documentation. autoheader: `pyconfig.h.in' is updated Should we stick with 2.50, or make configure.in compatible with 2.53? I do think that we should agree on using the same version of autoconf, to prevent huge massive changes to the configure script each time someone with a different version regenerates it. --Guido van Rossum (home page: http://www.python.org/~guido/)
participants (6)
-
barry＠zope.com -
Guido van Rossum -
M.-A. Lemburg -
Martin v. Löwis -
martin＠v.loewis.de -
Skip Montanaro