Since revision 4036 of errno.h, Tcl (8.4, 8.5, 8.6, any version)
cannot be compiled with mingw-w64 any more. The bug is
reported in Tcl's bug tracker as:
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3407070&group_id=10894
however the problem is the following line in mingw's errno.h
#define EOVERFLOW E2BIG
In windows, EOVERFLOW does not exist, but usual
applications define it as (Tcl does this as well):
#ifndef EOVERFLOW
# define EOVERFLOW EFBIG
#endif
Therefore, I suspect this is a typo (E2BIG should
have been EFBIG). However, I would recommend
to use the definition of Visual Studio 2010, which
gives EOVERFLOW (and other POSIX error codes)
a distinct value:
#define EOVERFLOW 132
In case you are planning to add more error codes
in the future, here is the complete list from
Visual Studio 2010:
#define EADDRINUSE 100
#define EADDRNOTAVAIL 101
#define EAFNOSUPPORT 102
#define EALREADY 103
#define EBADMSG 104
#define ECANCELED 105
#define ECONNABORTED 106
#define ECONNREFUSED 107
#define ECONNRESET 108
#define EDESTADDRREQ 109
#define EHOSTUNREACH 110
#define EIDRM 111
#define EINPROGRESS 112
#define EISCONN 113
#define ELOOP 114
#define EMSGSIZE 115
#define ENETDOWN 116
#define ENETRESET 117
#define ENETUNREACH 118
#define ENOBUFS 119
#define ENODATA 120
#define ENOLINK 121
#define ENOMSG 122
#define ENOPROTOOPT 123
#define ENOSR 124
#define ENOSTR 125
#define ENOTCONN 126
#define ENOTRECOVERABLE 127
#define ENOTSOCK 128
#define ENOTSUP 129
#define EOPNOTSUPP 130
#define EOTHER 131
#define EOVERFLOW 132
#define EOWNERDEAD 133
#define EPROTO 134
#define EPROTONOSUPPORT 135
#define EPROTOTYPE 136
#define ETIME 137
#define ETIMEDOUT 138
#define ETXTBSY 139
#define EWOULDBLOCK 140
Regards,
Jan Nijtmans
This indeed seems as a typo.
IMO, using the EFBIG solution (as can be found elsewhere, like:
http://ac-archive.sourceforge.net/largefile/dualexport.html or
http://ac-archive.sourceforge.net/largefile/dualmode_sources.print.html , etc...)
... with an ifdef would be the wise solution. JonY?
Using MSVC2010 values (as well as printing them here outright) can really
be a problem. I also have strong suspicions about trunk revs. 4430 and 4433
of errno.h by Kai.
Right, probably a typo, E2BIG seems to be completely unrelated, at least according to initial google results, maybe EINVAL?
I don't think we should use MSVC2010 values unless we can guarantee msvcrt.dll would give back the same values. This sounds hairy.
If msvcrt.dll doesn't touch any of those values at all, probably OK to move them into mingw-w64.
> If msvcrt.dll doesn't touch any of those values at all, probably OK to
> move them into mingw-w64.
msvcrt.dll doesn't have LFS, as far as I know, so it will never return
the EOVERFLOW error code.
IIRC, you added EOVERFLOW when you added LFS-ish support, and the two LFS links I referred specifically use EFBIG fas the EOVERFLOW replacement.
OK, ifdef it is.