[Tcl-bugs] [ tcl-Bugs-3474726 ] minGW Tcl_StatBuf not defined correctly in tcl.h

[SourceForge.net <no...@so...>]

Bugs item #3474726, was opened at 2012-01-16 22:36
Message generated for change (Comment added) made by nijtmans
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3474726&group_id=10894

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: 52. Portability Support
Group: current: 8.5.11
>Status: Closed
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: jeffrw (jeffrw)
Assigned to: Jan Nijtmans (nijtmans)
Summary: minGW Tcl_StatBuf not defined correctly in tcl.h

Initial Comment:
Windows Vista
minGW 5.1.4

configure correctly detects that struct _stat32i64 is not available, and compiles tcl and tk properly, because in the relevant windows code, tclWinPort.h is included with flag HAVE_NO_STRUCT_STAT32I64

But when attempting to compile freewrap, in tcl.h, Tcl_StatBuf is defined to be _stat32i64, and this leads to an error.

I can fix this by including tclWinPort.h and adding a define for HAVE_NO_STRUCT_STAT32I64, but since tclWinPort.h is not a member of the installed include directory, I infer this is not the intended solution.

----------------------------------------------------------------------

>Comment By: Jan Nijtmans (nijtmans)
Date: 2012-01-21 00:36

Message:
Done as proposed in all open branches.

Extensions which suffer from a mingw version without
_stat32i64 just have to compile with -D_USE_32BIT_TIME_T,
then everything will be fine. Then Tcl will use _stati64 in
stead of _stat32i64, while keeping full binary
compatibility with VC6.0

----------------------------------------------------------------------

Comment By: Jan Nijtmans (nijtmans)
Date: 2012-01-19 04:54

Message:
Even though this is not Tcl's fault, there is something we can do to
make it easier for extensions  to support older mingw versions.

Proposal: change the tcl.h line:
#         elif (defined(_MSC_VER) && (_MSC_VER < 1400))
to
#         elif (defined(_MSC_VER) && (_MSC_VER < 1400)) ||
defined(_USE_32BIT_TIME_T)

Then extension can simply define _USE_32BIT_TIME_T,
which makes Tcl use _stati64, which is available in all
mingw versions. Then the _stat32i64 definition in
tclWinPort.h is only necessary for cygwin, which makes
the detection logic unnecessary. It's much simpler,
both for Tcl and for extensions

----------------------------------------------------------------------

Comment By: Jan Nijtmans (nijtmans)
Date: 2012-01-18 07:35

Message:
Tried the workaround for freewrap, and it works. See attached
"freewrap.patch".

At least generic/zvfs.c compiles on win32 with this change, it should not
affect other
platforms.

----------------------------------------------------------------------

Comment By: Jan Nijtmans (nijtmans)
Date: 2012-01-18 00:15

Message:
_stat32i64 is supposed to be defined in stat.h, since VS2005, See:
    http://msdn.microsoft.com/en-us/library/14h5k7ff%28v=vs.80%29.aspx
Before that, this structure was named _stati64, but since VS2005
the _stati64 definition became dependent on the _USE_32BIT_TIME_T
macro. We cannot force extensions to set _USE_32BIT_TIME_T,
therefore the workaround to include the _stat32i64 structure
in tclWinPort.h if not available elsewhere.

The real solution is to use a mingw version which has a _stat32i64
definition in sys/stat.h. Another workaround for freewrap could
be to use the fact that if _USE_32BIT_TIME_T is defined
that then _stati64 is the same as _stat32i64. So, freewrap
could use something like (untested!!!):

#define _USE_32BIT_TIME_T
#include <sys/stat.h>
#ifndef _stat32i64
#   define _stat32i64 _stati64
#endif
#include <tcl.h>

See bug 3288345 for more details where this problem come from.
Anyway, it's up to mingw to provide a _stat32i64 definition, or
up to freewrap to provide a workaround when it wants to support
a mingw version which lacks _stat32i64

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=110894&aid=3474726&group_id=10894