[cmake-developers] Parallel build of cmake-2.8.3 intermittently fails using "MinGW Makefiles" generator under wine

Alan W. Irwin irwin at beluga.phys.uvic.ca
Wed Dec 8 18:24:03 EST 2010


On 2010-12-04 22:16-0800 Alan W. Irwin wrote:

> So "MinGW Makefiles" is a reasonable workaround for the parallel build
> troubles I was having with the "MSYS Makefiles" generator on wine.
> However, I think the next step in debugging those troubles is for
> somebody with access to Microsoft Windows to try to verify those
> troubles using the latest MinGW/MSYS tool chain you get with the
> automatic installer.

Well, I did some further experiments with "MSYS Makefiles" which all
failed.  Then I tried a clean parallel build of cmake again using
"MinGW Makefiles".  This time it also failed using exactly the same
"MinGW Makefiles" build script that previously succeeded. So it
appears both the "MSYS Makefiles" and "MinGW Makefiles" generators
create unreliable parallel builds of cmake under wine.

Intermittent failure/success like this is common when there are
dependency troubles in a project's source code (in this case,
cmake-2.8.3) since whether or not an error is generated depends
critically on the timing of the various components of the build.
Also, the wine development environment toolchain is quite slow so its
timing is going to be quite different than a Linux build or MS windows
build on the same machine.

I have attached the compressed (gzip) cmake output and the make -j4
output for any CMake developer that want's to analyze this "MinGW
Makefiles" failed parallel build on wine in some detail.  However, it
appears to me that the critical issue is some of the static libraries
are getting linked twice, e.g.,

wine at raven> grep "^Linking.*\.a" make_install.out
Linking CXX static library libcmsys.a
Linking C static library libcmsys_c.a
Linking C static library libcmlibarchive.a
Linking C static library libcmzlib.a
Linking C static library libcmzlib.a
Linking C static library libcmcurl.a
Linking C static library libcmcurl.a
Linking C static library libcmbzip2.a
Linking C static library libcmcompress.a
Linking C static library libcmexpat.a
Linking CXX static library libCMakeLib.a

It is that second link attempt of libcmcurl.a that causes the critical
"Z:\home\wine\newstart\MinGW\bin\ranlib.exe: 'libcmcurl.a': No such
file" error for this particular parallel build using "MinGW
Makefiles".  Note, on my previous "MinGW Makefiles effort that
finished without errors, I noticed the same double linking messages,
but apparently for that run, the time when those double linking
attempts overlapped was sufficiently different that it didn't cause
the "file not found" error.

To investigate further, under Linux with the usual gcc tool chain,
gmake, etc., I did a parallel build of cmake following what was done
for the wine build above.

software at raven> cmake -DCMAKE_INSTALL_PREFIX=/tmp/cmake_install \
~/cmake/cmake-2.8.3 >& cmake.out
software at raven> cmake --version
cmake version 2.8.3
software at raven> make -j4 install >& make_install.out

That finished without obvious errors.  I haven't bother attaching
those *.out files,  but there were duplicate linking messages
in this case as well:

software at raven> grep "^Linking.*\.a" make_install.out Linking C static library 
libcmzlib.a
Linking C static library libcmcompress.a
Linking C static library libcmbzip2.a
Linking C static library libcmbzip2.a
Linking C static library libcmexpat.a
Linking CXX static library libcmsys.a
Linking C static library libcmlibarchive.a
Linking C static library libcmlibarchive.a
Linking C static library libcmForm.a
Linking C static library libcmcurl.a
Linking C static library libcmcurl.a
Linking CXX static library libCMakeLib.a
Linking CXX static library libCMakeLib.a
Linking CXX static library libCPackLib.a
Linking CXX static library libCTestLib.a

Does this mean the duplicate linking messages (which both for wine and
Linux occur only for some of the static libraries) are some artifact
that should be ignored pending a bug fix to clean that up, or does it
mean the links are actually happening twice on Linux as well?  If the
latter, that means the potential also exists under Linux to have
errors due to duplicate link steps, but because the component timing
is different under Linux than it is under wine, by chance no error is
currently generated under Linux.

My next step is to try a parallel build of PLplot under wine using
both generators.  The PLplot build does not use quite as many
instances of add_custom_command (with the potential to screw up
associated target and file dependencies) as the CMake build (118
instances for PLplot versus 180 instances CMake), but nevertheless it
is a good test of whether either/both the "MinGW Makefiles" and "MSYS
Makefiles" generators are capable of producing reliable parallel
builds with a completely independent and quite complex build system.

Meanwhile, I would appreciate some response here from the CMake
developers at least about the duplicate Linking message issue noted
above as well whether they have ever seen a reliable parallel build of
cmake-2.8.x with either of the "MSYS Makefiles" or "MinGW Makefiles"
generators?

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); PLplot scientific plotting software
package (plplot.org); 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
__________________________
-------------- next part --------------
A non-text attachment was scrubbed...
Name: cmake.out.gz
Type: application/octet-stream
Size: 4430 bytes
Desc: gzipped cmake output under wine for 'MinGW Makefiles'
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101208/5b88bfff/attachment-0004.obj>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: make_install.out.gz
Type: application/octet-stream
Size: 4144 bytes
Desc: 'gzipped make -j4 install' output under 'MinGW Makefiles'
URL: <http://public.kitware.com/pipermail/cmake-developers/attachments/20101208/5b88bfff/attachment-0005.obj>


More information about the cmake-developers mailing list