Red Hat Bugzilla – Bug 89286
Binary compatibility broken: Incorrectly built binary which accesses errno, h_errno or _res directly.
Last modified: 2016-11-24 09:56:02 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.2.1) Gecko/20030225
Description of problem:
When trying to run binaries compiled on a rather old Linux system,
these binaries output the following message on file descriptor
"Incorrectly built binary which accesses errno, h_errno or _res directly."
Since some of these binaries are used as filters, this message
obviously destroys the standard output stream.
The vendor refuses to recompile his software, since he wants to
keep binary compatibility with older systems, since some of the
customers are refusing to upgrade their operating systems.
Is there a way to turn off this message or to redirect it to
'stderr' instead? Setting the environment
variable "LD_ASSUME_KERNEL" to value "2.2.5" didn't help.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
Obviously you need this binary product. :-(
If you have one, reproducing is simple Even running any binary
with --help shows the messages.
Actual Results: The string "Incorrectly built binary which accesses errno,
h_errno or _res directly." appaears on stdout before any of the programs in
question starts up.
Expected Results: The message should not appear or at least should appear on
The same applications are used to run fine on Red Hat 5.2 up to and
including Red Hat 8.0, SuSE Linux 6.2 up to and including the
recently released SuSE Linux 8.2 and on Mandrake 8.2, 9.0 and 9.1.
I mean, fixing this bug doesn't mean he suddenly looses binary compatibility.
He just needs to #include <errno.h> (for errno, or <netdb.h> for h_errno or
<resolv.h> for _res) in all source files before first use of errno (resp. h_errno
resp. _res). The standard clearly says errno can be a macro and since at least 1996
this is the case in glibc.
When the vendor fixes its software this way and recompiles against whatever glibc
he used for his current binaries, it should work just fine on RHL9 and any future
systems with --with-tls --with-__thread glibc (e.g. all systems with NPTL).
I think Peter's point is still a valid description of an erroneous warning.
1. "The standard clearly says that errno can be a macro and since at least
1996 this is the case in glibc." The 1995 POSIX std and the C language std do
NOT say errno MUST be a macro.
2. While it seems to make sense to report this error in conjunction with
threading, is there a reason to NOT support errno as an int on an older (non
threaded) application. What is the reason for losing compatibility with older
non threaded code? Why did this become such a critical change that it
requires a warning message. It causes large sections of code that once ran to
become unusable. The 1990 spec was loosened, not discarded.
You mean want to see bug#90002 which demonstrates that there
is a binary compatibility issue with '_res'.
I regard this change to be a significant API change (yes, its now closer to the
spec, but its still an API change) which should not have happened without major
versioning updates and supplying compat-libraries.
I propose that instead of emmitting that warning, the program REFUSE TO RUN
unless some special environment variable is set.
I have just spammed our local LUG list with some 100 copies of a message because
QMail/serialmail MALFUNCTIONED by not removing already delivered email.
Recompiling the affected programs after fixing the include errno.h fixed
Again: this API Change obviously CAN BE HARMFUL, so just letting the program run
is not that good an idea.
Try using diferent values for LD_ASSUME_KERNEL, see this