Re: autoconf-2.62 doesn't build on RHEL4

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Ralf Corsepius on 4/22/2008 6:36 AM:
|> |
|> | ... now, autoconf is forcing me to also ship gm4.

Which is a good thing for developers.  Anyone actively developing a
package can be assumed to understand the importance of using working
tools, and won't mind the extra distribution of gm4 in order to do
development.  And remember, the audience of developers is MUCH smaller
than the audience of users.  Whether or not autoconf makes detection of an
adequate m4 a hard requirement does not change the fact that an inadequate
m4 produces broken configure files; we chose to make it a hard error
rather than living with silent breakage, to emphasize this point; but even
autoconf 2.59, which did not enforce m4 versions, will benefit from having
a working m4 installed.

|
| Requiring (or even bundling) one particular flavor of a shell would
| likely significantly simply configure scripts :()

You're comparing apples and oranges.  Requiring a particular shell would
mean that ./configure is no longer the first step of a user's experience -
the user must first install the adequate shell.  There is nothing wrong
with requiring developers to have more tools than a user.

| OK, so running autoconf is a SECURITY risk on almost all existing Linux
| distributions?

No, running autoconf is generally not a security risk, even if you have an
insecure m4.  While there is a security risk if a developer is crazy
enough to request autom4te to freeze a file with an insecure name, the
odds of that happening are quite slim (after all, the bug escaped
detection for more than 13 years).  Besides, autoconf itself does not use
autom4te in this manner (it only freezes to portable file names such as
m4sugar.m4f), therefore it does not tickle this particular m4 security hole.

|
| It's time autoconf dumps using m4 in favor something more stable!

Go ahead - this is open source, so you are free to implement your own
program that does just that, and it won't hurt our feelings.  But on this
list, we are sticking with m4 unless you take the time contribute a patch
that is measurably better, rather than merely griping about the current
state of things.

| I guess you know how old and broken Cygwin's GCC is?
|
| I guess, I'll start to require gcc-4.3.x for my sources, such that
| Cygwin users will have to upgrade their GCC.

Apples to oranges again - supporting multiple compilers from the user's
perspective is different than requiring particular m4 from the developer's
perspective.  But yes, you are free to make that move, and when you do
make it, you can also consider abandoning your use of autoconf (after all,
once you decide to require a specific compiler of your users, what is left
for configure to determine about portability?).

- --
Don't work too hard, make some time for fun as well!

Eric Blake             address@hidden
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAkgN5d8ACgkQ84KuGfSFAYB50QCeOT235LVHRsdcZgp3kLV3GSY3
LTkAmgOJHBYXZn2CWQY60pMatdryAIsN
=/0cm
-----END PGP SIGNATURE-----