Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sourceware DOT cygnus DOT com>
List-Archive: <http://sourceware.cygnus.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sourceware DOT cygnus DOT com>
List-Help: <mailto:cygwin-help AT sourceware DOT cygnus DOT com>, <http://sourceware.cygnus.com/ml/#faqs>
Sender: cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To: mailing list cygwin AT sourceware DOT cygnus DOT com
X-Authentication-Warning: hp2.xraylith.wisc.edu: khan owned process doing -bs
Date: Wed, 26 Jan 2000 22:11:03 -0600 (CST)
From: Mumit Khan <khan AT NanoTech DOT Wisc DOT EDU>
To: Chris Faylor <cgf AT cygnus DOT com>
cc: Glenn Spell <glenn AT gs DOT fay DOT nc DOT us>, cygwin AT sourceware DOT cygnus DOT com
Subject: Re: Using h_errno, errno etc Cygwin DLL globals [Re: Making wget]
In-Reply-To: <20000126202757.A6897@cygnus.com>
Message-ID: <Pine.HPP.3.96.1000126220250.15827F-100000@hp2.xraylith.wisc.edu>
MIME-Version: 1.0
Content-Type: TEXT/PLAIN; charset=US-ASCII

On Wed, 26 Jan 2000, Chris Faylor wrote:

> Bug report:
> 
> When compiling using gcc 2.97.43 and the Cygwin snapshot from 1999-8-31
> I get an incorrect success when building code which contains both
> h_errno and netdb.h.  My program compiles and links perfectly rather
> than giving me the correct error!!!!

I don't know what 1999-08-31 did with h_errno, and how it exported it. If
it was a "statically linked" global variable, much like what sys_errlist
used to be, then it's expected to work.

  $ nm libcygwin.a | grep h_errno

If you see _h_errno (no sign of 'imp' in the name), it's case 1 below
and it's an application-space global variable; if you see both _h_errno 
and _imp_ versions, then it's case 2 below; if you see *only* the _imp_ 
versions, it's case 3 below.

> What the heck is the deal here???  This failed to compile perfectly on
> Ultrix 4.2!!!  Has anyone else seen this problem??

I don't see a problem ;-)

Note the the version of gcc is irrelevant here, the only relevant items
are (1) if h_errno came from the DLL or came from the "static" part of
libcygwin.a, and (2) if former, whether the DEF file used the DATA tag
or not when exporting h_errno. 

Here're the scenarios:
 
1. h_errno is in the static part of libcygwin.a: in this case, it's just
   like any other application-space global variable, and you can safely
   declare it in your code as `extern int h_errno', and it'll work as
   expected.

2. h_errno comes from DLL, *and* cygwin.def did not use a DATA tag.
   In this case, the following code is will link correctly, but in all 
   likelihood crash:
     
     int
     main ()
     {
       extern int h_errno;
       h_errno = 5;
     }

3. h_errno comes from DLL, *and* cygwin.def DID use a DATA tag. In this,
   the code above will not even link.

Regards,
Mumit



--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com