Bug 89286

Summary: Binary compatibility broken: Incorrectly built binary which accesses errno, h_errno or _res directly.
Product: [Retired] Red Hat Linux Reporter: Peter Funk <pf>
Component: glibcAssignee: Jakub Jelinek <jakub>
Status: CLOSED NOTABUG QA Contact:
Severity: high Docs Contact:
Priority: medium    
Version: 9CC: gsar, joshua, ml, patrick.melo
Target Milestone: ---   
Target Release: ---   
Hardware: i686   
OS: Linux   
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2003-04-22 04:05:45 EDT Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Description Peter Funk 2003-04-22 03:54:44 EDT
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):

How reproducible:

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

Additional info:

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.
Comment 1 Jakub Jelinek 2003-04-22 04:05:45 EDT
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).
Comment 2 Patrick Melo 2003-05-15 19:55:19 EDT
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.  
Comment 3 Gurusamy Sarathy 2003-06-09 22:22:36 EDT
You mean want to see bug#90002 which demonstrates that there
is a binary compatibility issue with '_res'.
Comment 4 Mario Lorenz 2003-08-06 15:31:16 EDT
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
that problem.

Again: this API Change obviously CAN BE HARMFUL, so just letting the program run
is not that good an idea. 
Comment 5 Carlos Solis 2005-06-16 13:42:46 EDT
Try using diferent values for LD_ASSUME_KERNEL, see this