[cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine platform

[Alan W. Irwin]

The full message is waiting moderator approval because
of the length of the attachments.  So I am resending
it again without the attachments because it includes
some interesting results about the headers for the
most recent MinGW/MSYS.

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________

---------- Forwarded message ----------
Date: Fri, 16 Sep 2011 12:17:16 -0700 (PDT)
From: Alan W. Irwin <irwin at beluga.phys.uvic.ca>
To: Clinton Stimpson <clinton at elemtech.com>
Cc: Brad King <brad.king at kitware.com>, Bill Hoffman <bill.hoffman at kitware.com>,
     cmake-developers at cmake.org
Subject: Re: [cmake-developers] cmake-2.8.5 build error on the MinGW/MSYS/wine
     platform

On 2011-09-16 08:16-0600 Clinton Stimpson wrote:

> 
> First off, I want to be sure we understand that you are using wine only to 
> run
> windows binaries?  Correct?

Yes.  Windows MinGW/MSYS, and the Windows CMake-2.8.5 are being used to build
CMake (and other packages) under Wine.

> If that's the situation, then I don't see how this has anything to do with
> wine's header files.

But Wine does provide system run-time libraries such as msvcrt.dll. <aside>I 
know this because the scanf family of functions in that
library had a serious numerical precision issue (only 7 as opposed to
17 decimal digits of precision for converting doubles) which I
recently fixed with a patch. Then a Linux rebuild of patched wine
provided a better msvcrt.dll to Windows applications running under
Wine with the result that those applications had greatly improved
numerical precision for the system scanf family of routines. </aside>

So for every Windows system library in the Wine environment that is provided by 
Wine
such as msvcrt.dll shouldn't there be associated system headers?  If so, how
are those system headers being provided to the Wine environment?

> And you should not expect to see
> $prefix/include/wine/msvcrt/sys/types.h in the include chain for
> archive_read.c.obj.
> 
> I'd look at the mingw compiler and the header files used with that.


The command

find MinGW -type f |xargs grep -l _SSIZE_T_DEFINED

shows my version of MinGW does not #define _SSIZE_T_DEFINED.  However, a 
further
gcc -E -dD experiment (this time with binary cmake-2.8.5 building
cmake-2.8.5) showed MinGW/include/sys/types.h was in the #include
chain and the following section was preprocessed with each
#ifndef succeeding:

#ifndef RC_INVOKED
....

#ifndef _SSIZE_T_
#define _SSIZE_T_
typedef int _ssize_t;

#ifndef _NO_OLDNAMES
typedef _ssize_t ssize_t;
#endif
#endif /* Not _SSIZE_T_ */

....
#endif  /* Not RC_INVOKED */


That combination of

typedef int _ssize_t;
typedef _ssize_t ssize_t;

is the one killing the cmake build because the type of
archive_read_data in archive_read.c is ssize_t (which boils
down to int from the above), while it
is __LA_DECL __LA_SSIZE_T in archive.h.  __LA_DECL is
empty, while (because _SSIZE_T_DEFINED is not defined)
__LA_SSIZE_T is #defined to be long which is inconsistent
with int causing the broken build.

So you might come to the conclusion that the lack of a
_SSIZE_T_DEFINED #define is a MinGW issue, but that contradicts the
evidence from both Brad and Bill that cmake builds on Microsoft
Windows with MinGW/MSYS are not broken at all!  So unless their
best efforts (with a complete reinstall rather than just an update)
at obtaining the exact same MinGW/MSYS that I have
are inadvertently failing, then the only alternative to
explain their good result that I can see is the above

typedef int _ssize_t;
typedef _ssize_t ssize_t;

in MinGW/include/sys/types.h

is completely avoided or _SSIZE_T_DEFINED is #define'd by
some other non-MinGW system header on Microsoft Windows.

Probably, the best way to sort out exactly why the CMake build happens
(by accident?) not to be broken on MinGW/MSYS/Microsoft Windows is for
somebody with access to the latest MinGW/MSYS (done by a complete
reinstall rather than update) on Microsoftw Windows to compare with my
gcc -E -dD results.  To facilitate that comparison I have attached two
files, command.out which details what command I used to obtain those
results, and D.out.gz that gives the (compressed) results obtained.

Another possibility is to clean up what I believe is the cause of this
mess which is the use of fixed types rather than macro-defined types
in Utilities/cmlibarchive/libarchive/*.c code which are potentially
inconsistent (as in this case) with macro-defined types in 
Utilities/cmlibarchive/libarchive/archive.h.

However, my opinion about that inconsistency could be incorrect so I
would like to hear from Brad or Bill whether there is some good reason
for the inconsistency in the way function types and arguments are
defined in Utilities/cmlibarchive/libarchive/*.c and
Utilities/cmlibarchive/libarchive/archive.h?

Alan
__________________________
Alan W. Irwin

Astronomical research affiliation with Department of Physics and Astronomy,
University of Victoria (astrowww.phys.uvic.ca).

Programming affiliations with the FreeEOS equation-of-state
implementation for stellar interiors (freeeos.sf.net); the Time
Ephemerides project (timeephem.sf.net); PLplot scientific plotting
software package (plplot.sf.net); the libLASi project
(unifont.org/lasi); the Loads of Linux Links project (loll.sf.net);
and the Linux Brochure Project (lbproject.sf.net).
__________________________

Linux-powered Science
__________________________