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: | glibc | Assignee: | Jakub Jelinek <jakub> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 9 | CC: | fweimer, gsar, joshua, ml, patrick.melo |
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2003-04-22 08:05:45 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. Reason: 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. Try using diferent values for LD_ASSUME_KERNEL, see this http://people.redhat.com/drepper/assumekernel.html |
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 'stdout': "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): glibc-2.3.2-11.9 How reproducible: Always 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 'stderr' instead. 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.