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

[Bill Hoffman]

Can you try and build CMake 2.8.4, then 2.8.3 and see what happens?



On 8/27/2011 7:22 PM, Alan W. Irwin wrote:
> As an experiment on the MinGW/MSYS/wine platform I tried to
> build cmake from the bash.exe command line as follows:
>
> cmake -G "MSYS Makefiles" \
> "-DCMAKE_INSTALL_PREFIX=/z/home/wine/newstart1/cmake/install" \
> /z/home/software/cmake/cmake-$CMAKE_VERSION >& cmake.out
>
> make >& make.out
>
> where CMAKE_VERSION=2.8.5,
> the above cmake command is executed with the windows binary version of
> cmake-2.8.5 you
> can download from kitware, make is the MSYS version, and I
> am using the 20110802 version of MinGW/MSYS.
>
> That make command errored out part way through with the following messages:
>
> [ 35%] Building C object
> Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.obj
>
> z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive_read.c:572:1:
> error: conflicting types for 'archive_read_data'
> z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive.h:386:30:
> note: previous declaration of 'archive_read_data' was here
> z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive_read.c:651:1:
> error: conflicting types for 'archive_read_data_into_buffer'
> z:/home/software/cmake/cmake-2.8.5/Utilities/cmlibarchive/libarchive/archive.h:411:22:
> note: previous declaration of 'archive_read_data_into_buffer' was here
> make[2]: ***
> [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/archive_read.c.obj]
> Error 1
> make[1]: ***
> [Utilities/cmlibarchive/libarchive/CMakeFiles/cmlibarchive.dir/all] Error 2
> make: *** [all] Error 2
>
> 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.
>
> This is a regression on successful cmake builds on MinGW/MSYS/wine that
> I have
> done before. However, I am not sure whether it is the new MinGW/MSYS
> (the new 20110802 version versus 20101030), the new wine (1.3.27
> versus 1.3.9), or the new CMake version (2.8.5 versus 2.8.3) that is the
> culprit here, but we should know more about that if somebody can tell
> me where the above macros are #defined.
>
> Note, I can do some experimentation with MinGW/MSYS/wine, but it
> should be intelligently focussed rather than brute force because the
> whole platform has a huge latency (literally a second) for every time
> cmake, make, or g++ are executed (and probably most other commands as
> well, although I have found at least one command in that environment
> [echo done from bash] that is just as fast as on Linux). As we know,
> cmake itself and well as the Makefile approach it configures tends to
> split stuff up into many little commands so when you multiply 1 second
> latency time the number of those commands, all cmake runs and make
> runs slow down dramatically when compared to the Linux platform. So,
> for example, I had to wait an hour or so for the above cmake command
> to finish that configured the cmake build. I have complained in the
> past about 0.1 second latencies for wine-1.3.9, but the current
> wine-1.3.27 seems to be ten (!) times worse in this regard.
>
> Despite this current latency drawback, the cmake/MinGW/MSYS/wine
> platform is
> quite useful for testing for Windows build issues if you don't want to
> spend a lot of time/effort/money on installing Microsoft Windows on
> your computer.
>
> For example, the above could be a MinGW/MSYS build issue that also
> occurs for Microsoft Windows for cmake-2.8.5 and the 20110802 version
> of MinGW/MSYS (the version that is automatically downloaded now
> by the automated MinGW/MSYS installer you can download using
>
> wget "http://sourceforge.net/projects/mingw/files/Automated MinGW
> Installer/mingw-get-inst/mingw-get-inst-20110802/mingw-get-inst-20110802.exe"
>
>
> Has anybody tried that version of MinGW/MSYS on Microsoft Windows to
> build cmake-2.8.5? It is possible the same build-time error will show
> up under those conditions.
>
> 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
> cmake-developers at cmake.org
> http://public.kitware.com/cgi-bin/mailman/listinfo/cmake-developers
>


-- 
Bill Hoffman
Kitware, Inc.
28 Corporate Drive
Clifton Park, NY 12065
bill.hoffman at kitware.com
http://www.kitware.com
518 881-4905 (Direct)
518 371-3971 x105
Fax (518) 371-4573