请教DC2004.12启动时的错误信息
总是会出现这个错误
Incorrectly built binary which accesses errno, h_errno or _res directly. Needs to be fixed
但是DC2004.12可以正常启动，Astro也可以启动，但是图形界面出现之前，也是
这么一段报错，请问高手这个到底是什么原因呢?
操作系统的版本问题 没关系
错误：Incorrectly built binary which accesses errno, h_errno or _res directly. Needs
to be fixed.
我找到了，以下说明应该时问题原因
Bug 89286 - Binary compatibility broken: Incorrectly built binary which accesses errno, h_errno or _res directly.
Bug#: 89286Product: Red Hat LinuxVersion: 9Platform: i686
OS/Version: LinuxStatus: CLOSEDSeverity: highPriority: normal
Resolution: NOTABUGAssigned To: jakub@redhat.comReported By: pf@artcom-gmbh.deQA Contact: bbrock@redhat.com
Component: glibc
URL:
Summary: Binary compatibility broken: Incorrectly built binary which accesses errno, h_errno or _res directly.
Keywords:
Status Whiteboard:
Description:
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 simpleEven 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.
------- Additional Comment #2 From Patrick Melo on 2003-05-15 19:55 -------
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.
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.