Description of problem: According to Eric Blake <ebb9> (upstream) gm4, all versions of gm4 prior to 1.4.11 suffer from serious bugs, which are not unlikely to break autoconf and to cause autoconf to generate broken configure scripts. I would recommend to upgrade m4 on all Fedora and RH releases. Particularily delicate: The versions of m4 as being shipped with RHEL 4 and below are such kind of old contemporary autoconf doesn't work on them. => Not upgrading m4 on these distros disqualifies RHEL <= 4 as development environment.
Some clarification: all versions of GNU m4 1.3 through 1.4.10 have at least one known stack-overflow (arbitrary code execution) bug, fixed in m4 1.4.11, when the -F option is abused. Additionally, autoconf 2.62 explicitly requires m4 1.4.5 or greater (because earlier versions can generate corrupt configure files), but can safely use 1.4.5 (now 21 months old) without tickling the security bugs present in those older versions, and without generating corrupt configure files. Earlier versions of autoconf also require m4 1.4.5 or greater to avoid corrupt configure files, although the dependency was implicit rather than explicit: http://lists.gnu.org/archive/html/bug-autoconf/2006-11/msg00025.html http://lists.gnu.org/archive/html/autoconf-patches/2007-02/msg00000.html Therefore, while upgrading to m4 1.4.11 would be nice, it is sufficient for autoconf's purposes to upgrade only to m4 1.4.5 (or at least backport the security fixes and the tracing bug fix to an earlier m4), and this should be done whether or not you upgrade to autoconf 2.62 in the near future, since all versions of autoconf are vulnerable to the pre-1.4.5 bug. Meanwhile, on BSD-based platforms, m4 1.4.10 also generates corrupt configure files; but as RHEL uses glibc and not BSD stdio, this is not an issue for RHEL. And eventually, when m4 1.6 is released, it will be incompatible with the stock autoconf 2.59, although the autoconf team has prepared patches that against 2.59 that will allow it to work with m4 1.6. http://git.sv.gnu.org/gitweb/?p=autoconf.git;a=shortlog;h=refs/heads/branch-2.59
Ralf, thanks for report, Eric, thanks for clarification. I updated to m4-1.4.11 in rawhide. I will not do rebase of m4 in older Fedoras - newest Fedora with m4 version bellow 1.4.5 is Fedora 5. Ralf, if you're RHEL customer, please contact support to resolve this in RHEL. (My opinion: RHEL5 - m4-1.4.5 (no changes IMHO), RHEL4 - m4-1.4.1 (maybe backport security fixes and tracing bug fix?), RHEL3 - m4-1.4.1 (we fix only hight priority security problems, so no changes IMHO).) Thanks!
(In reply to comment #2) > Ralf, if you're RHEL customer, please contact support to resolve this in RHEL. I am not - I am simply co-leader and maintainer of an opensource project (http://www.rtems.org) which has supported CentOS4 as one of their development platforms. As our development will be based on autoconf-2.62 (which mandates using gm4-1.4.5), not upgrading RHEL4 (and CentOS4) simply closes out CentOS4 and RHEL4 from being used as a development platform for your works and will force us to discontinue supporting CentOS4/RHEL4. I had hoped to be able to avoid this step - Your decision however makes it inevitable.
Ralf, I did no decision in RHEL case. Please file a bug against m4 and particular RHEL version to let product management consider and prioritize your request. Do the same with autoconf, if you wish new version in RHEL.