Subject: RE: undefined errno in libftp
From: [email-masked] (Colin Peters)

6 Mar 1998 22:13:15 -0800
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain;
	charset="iso-8859-1"
Content-Transfer-Encoding: 7bit
To: <[email-masked]>
Cc: "GNU-Win32" <[email-masked]>

Francisco Javier Diez <[email-masked]> wrote:
>I am trying to build the Library for ftpd clients (libftp) from Oleg Orel
>in Windows NT ( SP3 ). I built it in Solaris with no problem but when I
>build it in windows NT I get the next error;
>
>FtpLibrary.h:105: field `__errno' declared as a function
>
>There is a struct;
>
>typedef struct/* All structure initialize from edited struct FtpInit */
>{
>...
>
>int errno;        /* Last error code */  ( FtpLibrary.h:105)
>
>...
>}
>
>If I add the next code to the FtpLibrary.h
>
>#ifndef __CYGWIN32__
>extern int errno;
>#else
>#include <errno.h>
>#endif
>
>I can build the library, but when I try to build a program I get the next
>message:
>
>FtpLogin.c:70: undefined reference to `errno'

The problem is, basically, that for errno to be accessible from the cygwin
DLL they copied a trick often used by MS (if I'm not mistaken). Basically,
they have a function, probably called __errno, which returns a pointer to
the errno inside the DLL and then they #define errno to be something like

#define errno (*(__errno()))

That is, the value pointed to by the return of __errno. Obviously if you
have structures, classes or automatic variables called errno that define is
going to wreak havoc. And it appears the ftp library is having it's havoc
wreaked...

Please note, this is a guess as to exactly what is happening. I'm fairly
sure that it is something like this, but the details might be a bit off.

It may be possible, if you are very careful, to isolate those modules which
use the errno global variable from those that make use of the structure with
the errno member, but I doubt it. Probably the only workable solution is to
treat errno like a reserved word and change the name of the structure member
(and change it everywhere it is referenced, ack!).

This problem could be avoided if, like recent compilers from MS, we could
get gcc to handle references to global variables in a dll. Unfortunately
this would probably involve a lot of Win32 specifics inside gcc and friends,
perhaps to the extent of having a new attribute for variables exported from
DLLs (and functions too while we're at it). It doesn't seem likely to me
that this is going to happen in the near future, so I think you would be
best off changing the library you are using.

Good luck,
Colin.

-- Colin Peters - colin at fu.is.saga-u.ac.jp
-- Saga Univ. Dept. of Information Science
-- http://www.geocities.com/Tokyo/Towers/6162/index.html
-- http://www.fu.is.saga-u.ac.jp/~colin/index.html

-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".