'errno' horrors...

[John Wofford]

I'm sure the developers are all well aware of the issues with glibc 2.3.2
and errno.  For a basic recap for those who aren't aware, as of glibc
2.3.2 it is no longer acceptable to explicitly declare errno as a global
integer (i.e. no more "extern int errno;", but rather errno.h is to be
included (#include <errno.h>).  The reasoning for this is all good and
well, but it has broken some very important modules (for instance, php).

I certainly wouldn't be suprised if this has been discussed before, so
bear with me if it has been.  I know for me personally this has been a
pretty severe issue.  Much of my serving software (php, qmail, ucspi-tcp,
etc) fails to compile with glibc 2.3.2.  I'm sure it has been an issue for
others as well.  What is the stance of the developement team on this?  I
certainly wouldn't mind seeing 1. custom patches for broken modules or, 2.
a temporary revert to glibc 2.3.1 while this issues are fixed.

Yes, I know, I can personally revert to 2.3.1 and hold the module, but it
seems odd to allow key modules to be broken by the default libraries.  It
also seems to go against the stance that Lunar has taken in the past
(stability as a priority; how long did Lunar refrain from updating the
2.4.18 linux kernel over minor stability issues?)

What is the stance of the development team on this issue?

-John