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

[Alan W. Irwin]

On 2011-08-27 16:22-0700 Alan W. Irwin wrote:

> If you compare the types of archive_read_data and
> archive_read_data_into_buffer in archive_read.c versus
> archive.h, the *.c versions are
>
> ssize_t
> archive_read_data(struct archive *_a, void *buff, size_t s)
>
> int
> archive_read_data_into_buffer(struct archive *a, void *d, ssize_t len)
>
> while the *.h versions are
>
> __LA_DECL __LA_SSIZE_T archive_read_data(struct archive *,
>                    void *, size_t);
>
> __LA_DECL int archive_read_data_into_buffer(struct archive *,
>                void *buffer, __LA_SSIZE_T len);
>
> So it appears on the MinGW/MSYS/wine platform at least that
>
> something is screwed up with the __LA_DECL and/or __LA_SSIZE_T macros.

Hi Bill:

As promised, I am now following up with -E -dD information (for
the case of binary cmake-2.8.3 building cmake-2.8.3, but I
assume the results would be identical for 2.8.4 and 2.8.5 since
I got the same build errors for them).  This combination
of options really does the job, and I wish I had thought of
them sooner.

>From the above __LA_DECL must have an empty #define, and 
__LA_SSIZE_T must be #defined to ssize_t to avoid
the build error.  Also, the above declarations of the functions
occur on lines 308 and 407 of
/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive.h

-dD output says the following concerning __LA_DECL prior to lines 308
and 409 (it was changed later on, but that is not relevant)

# 98
"z:/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive.h"
#define __LA_DECL

So that shows the desired empty result which avoids any build error
from this cause.  However, I was surprised the whole thicket of
preprocessing directives just above line 98 in that file (which #define
__LA_DECL to different values) was somehow avoided.

-dD output say the following concerning __LA_SSIZE_T

The second #define after

# 54
"z:/home/software/cmake/cmake-2.8.3/Utilities/cmlibarchive/libarchive/archive.h"

is

#define __LA_SSIZE_T long

which is inconsistent with the ssize_t function type for
archive_read_data in archive.c which causes the build error.

The relevant preprocessing code after line 54 is

#define __LA_INT64_T    __int64
# if defined(_SSIZE_T_DEFINED)
#  define __LA_SSIZE_T ssize_t
# elif defined(_WIN64)
#  define   __LA_SSIZE_T    __int64
# else
#  define   __LA_SSIZE_T    long
# endif

The -dD results show that _SSIZE_T_DEFINED is not #defined, allthough
they do show the following:

#define _SSIZE_T_
typedef int _ssize_t;
typedef _ssize_t ssize_t;

Furthermore, they show that _WIN64 is not #defined (which makes sense
since my platform is 32-bit wine on a 64-bit hardware platform
(amd64)).

But the point is both the __int64 and long result would cause a broken
build because ssize_t is typedef'ed to int on (32-bit) wine. So in
sum, it looks like the CMake code avoids a broken build on wine (and
other platforms with ssize_t typedef'ed to int) only if
_SSIZE_T_DEFINED is always #defined.

I then tried

export CFLAGS='-O3 -D_SSIZE_T_DEFINED'

for a build from scratch of cmake-2.8.5 using cmake binary 2.8.5, and
it worked with no errors or warnings!  It is good to know that
workaround is available for the cmake build on wine (presumably
regardless of the "x" in cmake-2.8.x).  I doubt very much though
that I will have to be concerned with that workaround for builds
of other software that is not as complicated as the CMake build.

Of course, Wine _might_ be at fault here for not #defining
_SSIZE_T_DEFINED when ssize_t is typedefed.  But is that a standard
that you expect to be followed on all platforms or a Microsoft Windows
idiosyncrasy that more robust CMake code would not have to worry
about?

What I mean by that comment is the following.  The current situation is the
function and argument types in
cmake-2.8.x/Utilities/cmlibarchive/libarchive/*.c files do not use the
same macro-based approach as that used in
cmake-2.8.x/Utilities/cmlibarchive/libarchive/archive.h for defining
the types and arguments of functions.  That seems like an accident
waiting to happen (and, in fact, that accident has already happened on
wine.) Perhaps there is some reason for this fundamental inconsistency
in the definitions of the function types and arguments in the
libarchive code, but I don't understand what that reason might be.

I know virtually nothing about Windows platforms.  So if you think it
should be an expected standard, could you advise me where
_SSIZE_T_DEFINED is #defined for Microsoft Windows so I could advise
Wine to do the same in their equivalent header?  I could find nothing
official from Microsoft about _SSIZE_T_DEFINED in a google search.
Instead, there appeared to be mostly google hits for projects #defining
_SSIZE_T_DEFINED themselves.

If you advise me to go ahead with the wine bug report, I assume they
would eventually act on it as a low priority since they claim to want
to follow every Microsoft Windows idiosyncrasy that makes a practical
difference.  Of course, that does not mean that CMake code should
necessarily use an inconsistent and non-robust approach for defining
function types and arguments in the libarchive code.  Of course, I
could also be wrong about the necessity of that approach.... :-)

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
__________________________