[14241] in SIPB bug reports
Re: sipb linux pine fixed
daemon@ATHENA.MIT.EDU (Greg Hudson)
Sat Jul 10 22:19:00 2004
From ghudson@MIT.EDU Sun Jul 11 02:19:00 2004
Return-Path: <ghudson@MIT.EDU>
Delivered-To: bug-sipb-mtg@CHARON.mit.edu
Received: (qmail 27981 invoked from network); 11 Jul 2004 02:19:00 -0000
Received: from biscayne-one-station.mit.edu (18.7.7.80)
by charon.mit.edu with SMTP; 11 Jul 2004 02:19:00 -0000
Received: from melbourne-city-street.mit.edu (MELBOURNE-CITY-STREET.MIT.EDU [18.7.21.86])
by biscayne-one-station.mit.edu (8.12.4/8.9.2) with ESMTP id i6B2ILn8025923;
Sat, 10 Jul 2004 22:18:21 -0400 (EDT)
Received: from egyptian-gods.mit.edu (EGYPTIAN-GODS.MIT.EDU [18.101.0.162])
(authenticated bits=56)
(User authenticated as ghudson@ATHENA.MIT.EDU)
by melbourne-city-street.mit.edu (8.12.4/8.12.4) with ESMTP id i6B2IJOn011368
(version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT);
Sat, 10 Jul 2004 22:18:20 -0400 (EDT)
Received: (from ghudson@localhost) by egyptian-gods.mit.edu (8.12.9)
id i6B2II9m022837; Sat, 10 Jul 2004 22:18:18 -0400
Subject: Re: sipb linux pine fixed
From: Greg Hudson <ghudson@MIT.EDU>
To: Jacob Morzinski <jmorzins@mit.edu>
Cc: bug-sipb@mit.edu
In-Reply-To: <Pine.LNX.4.30L.0407101412050.29102-100000@opus.mit.edu>
References: <Pine.LNX.4.30L.0407101412050.29102-100000@opus.mit.edu>
Content-Type: text/plain
Content-Transfer-Encoding: 7bit
Message-Id: <1089512297.24763.467.camel@egyptian-gods.mit.edu>
Mime-Version: 1.0
X-Mailer: Ximian Evolution 1.4.5
Date: Sat, 10 Jul 2004 22:18:18 -0400
On Sat, 2004-07-10 at 18:18, Jacob Morzinski wrote:
> RHEL 3 won't run programs that were compiled on RedHat 7, if
> the programs use certain types of errno syntax. (The error
> message is: "Incorrectly built binary which accesses errno
> or h_errno directly. Needs to be fixed.", and in my case the
> program segfaults.) Note that RHEL 3 will happily run the exact
> same code if it is compiled on RedHat 6 or compiled on RedHat 9.
> RedHat 7.3, though, poisons the binary. Why? Because it can.
I can't really explain all of this behavior, but in theory, the faux pas
is to use "extern int errno;" instead of "#include <errno.h>".
