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 aressize_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 __________________________ _______________________________________________ cmake-developers mailing list [email protected] http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
