glibc 2.2.5 incompatibility for (old) existing binaries.

[runge@karlrunge.com (Karl J. Runge)]

Hi,

I apologize if this is not the correct mailing list to ask this question;
if possible please let me know if there is a better place to ask it.

I'm wondering if any of you have seen this problem and have any
suggestions.

In doing some experimental upgrades to Debian 3.0 on test machines
on our LAN, I noticed an incompatibility: applications built on glibc
2.0.7 (i.e. 1999 timeframe) now often fail unexpectedly on Debian 3.0
(glibc 2.2.5).

I traced the problem to the perror()/error()/stderr behavior.  Typical
problem is the application hits an error condition and the message does
not come out to stderr and the application appears to exit abnormally.
Sometimes an application dies with segmentation violation, but the
typical behavior is a silent death (and so took me a while to notice it).

A application like this shows the simplest form of the failure:

#include <stdio.h>
#include <errno.h>
#include <unistd.h>

/* cc -o perror_test perror_test.c */

main() {
	char file[] = "/tmp/NONO";	/* non-existent file */
	if (access(file, F_OK) == 0) {
		fprintf(stderr, "%s is F_OK\n", file);
		return 0;
	} else {
		fprintf(stderr, "calling perror (errno=%d)\n", errno);
		perror(file);
		fprintf(stderr, "called perror.\n");
		return 1;
	}
}

I compile this on a glibc 2.0.7 environment on an old machine, and
then see if that application binary works on a glibc 2.2.5 environment
(e.g. Debian 3.0).  No output comes to the screen from the perror() call.
Testing on a glibc 2.2.4 environment shows no problem.  I empirically
observe a number of apps crashing with segv, but have not tried to create
a simple test program that does that.

ltrace suggests the problem is in the GNU error() function that I
believe perror() can call.  Perhaps it is some incompatible way the
new glibc 2.2.5 handles the stderr data object?  I think there may be
other problems (i.e. outside of perror()/error()) but I haven't traced
them down.  Obviously this potentially affects all but the most trivial
application binaries...

I understand most folks think of glibc 2.0.7 as "ancient history", but
of all things glibc should be forward compatible with itself.  I have
literally 100's of applications built and tested in that timeframe that
are exported via NFS to linux machines on the LAN.  Now it seems I cannot
upgrade the linux machines without the daunting task of rebuilding and
retesting those 100's of applications.  Not a pleasant task!  Have you
heard of the this problem from anyone else, or am I the only one?
If nothing else, it would be nice to have someone to commiserate with!

Many thanks,

Karl Runge