Mail Archives: cygwin/2000/01/26/23:10:38
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
- Raw text -